EPUB 3 Working Group vF2F — 2nd Day — Minutes

Date: 2020-10-23

Attendees

Present: Tzviya Siegman, Ivan Herman, Brady Duga, Avneesh Singh, Wendy Reid, Matthew Chan, Toshiaki Koike, Deborah Kaplan, Yu-Wei Chang (Yanni), George Kerscher, Romain Deltour, Masakazu Kitahara, Philippe le Hégaret, Laura Brady, Gregorio Pellegrino, Juliette McShane, Toshiaki Koike, Charles LaPierre, Marisa DeMeglio, Garth Conboy, Juan Corona, Karen Myers, Zheng Xu (徐征), Hadrien Gardeur, Bill Kasdorf

Regrets: Matt Garrish

Guests: Dave Cramer, Courney Benett, Philippe le Hégaret, Judy Brewer, Karen Myers, Julie Johannessen, Fred Chasen, Ken Jones, Rachel Yager, Daniella Levy-Pinto, Danny Faris

Chair: Wendy Reid

Scribe(s): Matthew Chan, Karen Myers, Zheng Xu (徐征)

Dave Cramer: welcome everyone to day 2 to virtual TPAC for epub 3 wg
… we had a good meeting last night, sorted through a couple highly commented issues
… nav vs spine order, external entity declarations, started convos about testing and fxl accessibility
… now continuing with those last two topics
… do we have any new people who want to introduce themselves?

Matthew Chan: Judy introduces herself

Fred Chasen: i’m also new, from scribd. Just looking on as an observer for now and perhaps will join the process

Philippe le Hégaret: PLH, W3C

Philippe le Hégaret: hi, project manager for the w3, responsible for all the wg, thank you for your work

Daniella Levy-Pinto: hi, i’m a project coordinator for NNELS, happy to be here

Matthew Chan: Danny, also from NNELS, an accessibility developer, introduces himself

Tzviya Siegman: explains the irc queueing mechanism to the new folks

1. testing

Dave Cramer: epub 3.2 was done by the community group as a report, but didn’t go through the full w3c wg process
… we want to take advantage of w3c experience in developing spec
… we need to prove that everything in our spec is implementable, and we do that by showing 2 independent implementations
… yesterday we talked about history of previous attempts at doing this, e.g. epubtest
… it tried to be something like caniuse for epub, providing authors info about which features work on which rs
… epubtest faced significant problems, there are lots and lots of rs, and those rs behave differently even depending on which os they are on
… work kind of overwhelmed the volunteers
… it was also focused on testing large scale features vs normative statements in the spec itself
… the newer version of epubtest is working very well, is a great resource
… we going to need people to work on testing, including a test lead

Marisa DeMeglio: old epubtest: https://daisy.github.io/old-epub3-support-grid/features/

Dave Cramer: if you can, please volunteer!

Marisa DeMeglio: new epubtest: http://epubtest.org

Dave Cramer: we’re going to need a lot of planning re. our test approach, define what the scope of testing will be
… we can’t do every web platform test for css, but wrapped up in an epub
… ivan, should this be a separate github repo, just for testing? would be difficult to include it in the spec repo

Marisa DeMeglio: repo for the old epubtest test contents: https://github.com/IDPF/epub-testsuite

Ivan Herman: the spec repo is already pretty big, and will be subject to a tools like echidna; better to have a separate repo

Dave Cramer: maybe we can talk offline about how to do this

Ivan Herman: if you assign this to me, i’ll do it :-)

Dave Cramer: other thing that came up yesterday, browsers can be tested using test harnesses that can automate tests
… we don’t have that, so a lot of our testing is going to be manual, more laborious
… the other thing that came up last night, we need to do some experimentation, starting with a small corner of the spec, to determine how will we document, how we will collect normative statements from the spec/identify testable assertions, create testable content, how we will maintain all our epub test files…
… let’s try to work at a small scale to figure out what will work, and what won’t, before we start to try to tackle everything
… we’ll have to have a taskforce within the wg to do a lot of this, meeting and talking separately from the regular wg calls

Dave Cramer: https://docs.google.com/spreadsheets/d/1wOe-6MqFk296dCoRUmrd3ghmVXH3yM-i97hFOuGlX4k/edit#gid=708869567

Philippe le Hégaret: you have different categories of tests, e.g. unique tests
… we have test harness tech
… then you have tests that test sections, we don’t have any of those
… then you have marketing tests
… these tests were not so much aimed at testing implementation, but more at motivating conformance
… e.g. the happy face that showed up if you passed this type of test

Dave Cramer: http://acid2.acidtests.org/#top

Dave Cramer: http://acid3.acidtests.org/

Wendy Reid: for content authors, what testing information are you looking for, or would like to see as a result of the testing?
… this is aiming at the same thing as the acid tests (i.e. the final category), so authors can see how many rs have a smiley face for a feature they want to use

Tzviya Siegman: responding to wendy, good point. A big thing that discourages authors from using a feature is that they are unsure about interoperability
… i really like the idea of the acid tests
… a lot of devs do unit testing for their own rs, could we reuse some of these?

Dave Cramer: the tests that some of these rs have might be embedded into their development framework, and not reusable
… or they might be dealing with handling of invalid content, i.e. handling things that would never get through epubcheck
… these tests wouldn’t help us

Gregorio Pellegrino: is css support outside scope of these tests?
… i.e. using new css rules, etc.
… also, it would be useful to determine if metadata is used by rs
… also if rs use toc, landmark, etc.

Dave Cramer: i’ve started on a script that turns browser css tests into tests for epubs
… but if we start testing all css features, we’re never going to finish
… maybe css support is more an area for acid testing, as opposed to comprehensive unit testing

Wendy Reid: https://docs.google.com/spreadsheets/d/1wOe-6MqFk296dCoRUmrd3ghmVXH3yM-i97hFOuGlX4k/edit#gid=1730700660

Dave Cramer: re. the metadata test, that is definitely going to get tested. Some of these things correspond to assertions in the spec

Ivan Herman: how do we relate to the existing testing environment for css, svg, mathml?
… because epub’s content document are made of those, so we shouldn’t repeat work

Marisa DeMeglio: we should mine the old epubtest for content
… the process for building those test books should be streamlined, but once we determine what we want to test, we could look through the epubtest repo and see what we can reuse

Marisa DeMeglio: https://github.com/IDPF/epub-testsuite

Dave Cramer: agreed

Brady Duga: it’ll be harder for us to go through our own testing framework and pull tests for reuse vs just going through the spec and making new tests
… when it comes to the acid tests, as someone who tried to pass, I didn’t find them terribly useful
… you essentially had to implement everything before you could get a pass, no indication as to how close you are to passing, it was pass/fail

Philippe le Hégaret: the acid test was a marketing test, purely meant as motivation to implementors, that’s why it didn’t give an indication as to how close you were to being feature complete (according to the test)
… you won’t be able to test everything, so prioritize which areas of the spec are most crucial for testing

Romain Deltour: one of the primary sources of interop problems between rs is that spec is not clear on how rs should process content that is invalid
… should spec provide some guidance on error handling?

Tzviya Siegman: +1 to romain

Wendy Reid: +1 to romain

Dave Cramer: one interesting source of tests is bugs, if we want to decide how rs should respond to erroneous content, its difficult to do this in the abstract
… about the scope of testing, the scope should depend on the epub community and the wider ecosystem, but it also depends on demands of w3c management
… may have to consult “The Director”

Wendy Reid: any rs which fail our test shouldn’t see this as a mark against them, what we are testing is the quality of the spec

Tzviya Siegman: +1 wendyreid

Wendy Reid: it could be either that the rs hasn’t implemented properly, OR that the spec is really hard to implement/needs to be reworded

George Kerscher: at epubtest we will be continuing our accessibility testing, but in that process we end up testing a whole lot of things that the epub wg will end up testing
… maybe when we report these relevant results, we can report to the epub wg too

Philippe le Hégaret: about talking to the w3, look at it like a negotiation entering CR phase
… w3 will be reasonable

Charles LaPierre: although we need to consider that epubtest.org tests are all manual tests

Philippe le Hégaret: our goal is to make the web work, not to nitpick on the spec

Garth Conboy: re. George’s last comment, tests that determine things not covered by an in-spec assertion aren’t as relevant to our testing here
… those tests may be relevant to the individual rs, but might not be as relevant to us
… re. wendy’s comment, we should start with the must assertions, and just try to get the 2 independent implementations

Matthew Chan: re. marisa’s comment, we don’t need to test a lot of those higher level features

Judy Brewer: re. manual testing vs testing automation, large scale testing that w3 has done have been automated
… but testing in accessibility has been manual, so it would be good to point this out, and make a specific plan for these more laborious tests
… this also applies to the entire class of tests that have to be done manually
… what percent of your tests are: fully automatable/semi-auto/fully-manual req. human experts?

Romain Deltour: 0% fully automatable I’m afraid :/

Dave Cramer: i think fully automatable tests is 0% since we aren’t working in browsers, and cannot assume scripting support

Judy Brewer: i suggest you look for appointments with Phillipe and if needed also myself, to specifically look at testing challenges on rec-track, and how to scale that in light of the manual nature of a lot of your tests
… i was hoping more of your tests were already automated

Dave Cramer: this doc is trying to start identifying normative statements in our spec
… categorizing by topic and subtopic, listing the assertion itself, whether it is must/should
… this is an example of some of the work we need to start doing
… i think someone mentioned tooling that could automatically find some of the normative statements

Zheng Xu (徐征): we need to start with the must items, no need to spend time on css errors in the beginning
… re. css support, we can let the publishers work directly with the css cg
… we should start with a smaller scope of testing, and gradually expand scope as we develop our testing methods

George Kerscher: though js support is not required, some do. Can we automate testing on the rs that do support js?

Dave Cramer: not sure… that might present issues in terms of how we report results…

Judy Brewer: i understand someone from publishing area has been liaising with accessibility testing taskforce

Judy Brewer: has this resulted in any advances in getting testing automation?

Romain Deltour: I am (was really) in that group. i have an idea of what is going on in that taskforce, but that is more concerned with how those tests are worded, vs. how the testing is actually done

Judy Brewer: will follow up with the taskforce, and see if we need to focus more on enabling testing automation

Zheng Xu (徐征): if we don’t try automation testing, we’ll never know how well automation testing works

Avneesh Singh: During accessibility testing we observed 60% of the tested RS had Java Script support

Zheng Xu (徐征): the rs who can’t support these automatic tests might be able to make some changes to support these tests

Philippe le Hégaret: there are around 270 “musts” in the spec as is, and you have to test both the positive case, and the negative case
… plus, there are some assertions which aren’t phrased as must, but effectively are must statements
… then, where the spec includes algorithms, these effectively imply must statements as well
… remember that your time isn’t unlimited, time-bound your testing

Marisa DeMeglio: https://daisy.github.io/old-epub3-support-grid/features/

Marisa DeMeglio: https://github.com/IDPF/epub-testsuite/tree/master/content/30/epub30-test-0102/EPUB/xhtml

Marisa DeMeglio: re. epubtest (see above), there is a small section about scripting, beyond this section, we weren’t able to automate anything
… for that number of musts, are those content musts, or rs conformance musts?

Philippe le Hégaret: that’s both

Marisa DeMeglio: i’m noticing some musts that will be hard to test

Romain Deltour: part of this work will involve reworking conformance classes
… e.g. your content must have nav document - this is about content, this is easy to test, only a matter of creating a test content that has these features

Dave Cramer: re. marisa’s last, i’ve also found some musts that are hard to test. This process will help us reword the spec to make it more clear
… next step is to collect the people in the group who are interested in working on this

Wendy Reid: is there anyone interested in volunteering today?

George Kerscher: i chaired the rs accessibility working group so…

Dave Cramer: if possible I will contribute

Romain Deltour: certainly interested in contributing too!

Marisa DeMeglio: me too

Zheng Xu (徐征): me too

Brady Duga: i would like to participate

Deborah Kaplan: in theory, include me!

Ivan Herman: we need someone really willing to lead

Wendy Reid: we’ll organize that later

Matthew Chan: Daniella will also participate!

2. FXL A11y

Wendy Reid: https://comica11y.humaan.com/

Wendy Reid: this part of the session we will continue conversation we started last night on EPUB accessibility
… this link is fun, cool
… It’s a comic
… get to look at comics as part of work…who doesn’t love that!
… I did this introduction yesterday but will do it again today because we have a different audiences

Charles LaPierre: love the responsive design!

Wendy Reid: to make sure everyone gets the context
… one of the deliverables that we have in this WG
… is to update a number of documents, including the EPUB Accessibility Guidelines; 1.0 or 1.1 thanks to ISO
… one of biggest questions is fixed layout content, fixed layout accessibility
… a lot of publishers use for comics, cookbooks, magazines, text books; many use cases and needs
… especially as more publishers move to born accessible workflows
… we want things to be consistently accessible
… core spec has all the tools we need to make fixed layout accessible; HTML; SVG; CSS
… but we need guidelines to make a consistent experience
… put out a call on twitter, talked with people
… about content accessibility experiences
… Studio called Human in Australia
… spoke to developer Paul to walk me through the process
… it is a completely unsustainable way to produce content at scale
… what might be an outcome is creation of a tool
… for an automated tool for writing captions
… talking to other people, SVG was recommended a lot for description text and overlays
… other things were core best practices
… put in agenda an item written by Ken Jones
… we have outlined some in accessibility, but these core principles are very important
… see the rec and say reading order is important, but how do I apply it; how do I watch out for this problem
… other problem is tooling, if we can apply that
… not saying lack of tools is causing problem, but there is that
… some output from tools I have seen is crazy

Garth Conboy: A lot of time allocated to this topic
… wonder what we think the output will be
… you started out correctly
… you can write accessible content using fixed layout in text
… can use SVG
… and stroke every curve of every letter and it can be horrible
… are these…do we think what comes out of this is a set of best practices
… is that in the scope of this WG/
… or do we envision changes to FXL spec
… I’m curious how we envision “winning”?

Wendy Reid: what I would like to see come out of this conversation
… I have some ideas about directions, but as a group would like to discuss what is the best output
… I don’t think it’s changes to FXL stuff, tools are there
… I definitely see additions to the accessibility docs
… but I am opening up the floor
… I would like us to come out of this meeting
… with either a single direction to research, or have a few people go off to experiment and research different options
… we need a solution or series of recommendations that are implementable for content authors and reading systems
… one things from last night’s conversations, we might have to recommend different things for different content types
… for example, manga and text books may differ

Tzviya Siegman: Ken Jones’s notes https://paper.dropbox.com/doc/Accessibility-in-Fixed-Layout-EPUB-3il8mlIqLpUfHHhcZEmgy

Avneesh Singh: First step is to clarify from some fundamental things
… when it comes to EPUB Accessibility; EPUB 3.1 examples of low vision
… text spacing
… hard in fixed layout to meet such requirements

Avneesh Singh: http://kb.daisy.org/publishing/docs/fxl/index.html

Avneesh Singh: Matt has already written some best practices
… what we have done for last 2-3 years
… pretty clear from that
… if you are assuming we can find out some persistent way to ensure most of fixed layout can be EPUB accessible
… that is difficult; have to be realistic
… if you see the principles of accessibility, may be reflowable or fixed layout
… if standard way for reflowable; but more difficult for fixed layout
… purpose of techniques is for accessibility @
… the techniques goes into detail
… two scope areas
… one to provide ways of implementing…specific for EPUB, techniques for numbers and metadata
… and tell you how to apply WCAG
… applies to a web page
… whereas apply conformance into EPUB
… has to have a title; has to map to EPUB
… two purposes of technique
… fixed layout
… motivation behind FL is the @
… some people go into visual layout
… a better way is not to look at from Accessibility techniques POV, look at it as independent best practices
… when I proposed in charter, I said we would be exploring for fixed layout
… I did not say we would conform to WCAG
… in some cases we will succeed, but more ad hoc
… have to look at manga, how to inject accessibility
… main things to mention, let’s take an independent project from access. and techniques
… look at ways in which people are producing the fixed layout and then bring up the best practices
… during that process we may find there is a kind of unified approach that could work for 4050% of FL
… then we can look at best practices

Wendy Reid: I 100% agree with you

Charles: with 1.0 spec, geared to WCAG2.0
… and other is it has a baseline of WCAG single A
… we always thought we would raise the bar on that to AA
… on FL, we might say for Excel layout we would require a single A because of issues of WCAG AA for fonts spacing and the like
… that may not be possible
… we could relax that and go back to single A for these types of docs; something to consider

Wendy Reid: yeah, that is all brilliant
… trying to wrap my head around Avneesh’s wisdom

Deborah Kaplan: Maybe less require single A

Karen Myers: ..but FL has some limitations

Deborah Kaplan: no reason to drop to single A for things FL can do just fine, which is most things
… I think it would be reasonable for a guidance document to identify what you cannot do that are part of WCAG A, AA, AAA; things you cannot do in FL

Avneesh Singh: we are recommending AA but min is A
… making a decision on moving toward AA is already in WG charter
… WCAG2.1 is out a couple years
… what I want to elaborate
… we already have provision in EPUB access for optimized publications, for example audio books
… not accessible entirely, but for people who are visually impaired
… not say they are universally inaccessible

Charles LaPierre: totally agree

Avneesh Singh: for screen readers; doesn’t work for a low vision person
… should not need to scroll the text horizontally
… it may be accessible for screen readers, but may not be universally access; telling you what possibilities are there
… maybe for screen reader use, but doesn’t conform for EPUB access, but we can specific using metadata properties
… it has reading order TOC
… explain in summary; this can be a way
… following up on what Deborah mentioned

George Kerscher: I think that the comic and manga issue
… may end up being different than fixed layout solution
… looking at FL, wonder if it would be acceptable for a presentation to be different than
… the fixed layout view
… if the content would ignoring the
… layout still be presentable in a logical reading order
… and be essentially reflowed if that would
… so throw out FL aspects and as long as you still know it’s a heading
… and it comes before the body text it refers to
… if that is appropriate
… don’t think it’s just possible to have the same presentation and make it accessible to a person with low vision

Wendy Reid: I think everyone is making excellent points

Bill Kasdorf: +1 to George. FXL is fundamentally all about visual appearance.

Marisa DeMeglio: Looking at an example; looking at viewpoint in HTML metadata; looking at heighth and width
… is it common to target one specific size?

Wendy Reid: depends upon size of page, image size

Garth Conboy: setting an aspect ratio; very common, almost universal

Marisa DeMeglio: thinking about ways to arrange the content
… for different sized screens
… not sure if these reading systems have scrolling ability or have fixed pagination for everything
… not the time to do this yet; just thinking about our options

Wendy Reid: good point
… I have never seen a FL book
… where there is media queries
… this aspect ratio for iPads, iPhone
… what I have often seen in reading systems
… designed for a tablet or laptop sized screen; see phone reading systems offer zoom and pan; automatic panning
… or pinch to zoom as big or small as you want
… lets you move around the page; that has been the common affordance of reading systems
… especially on phones
… on ipad screen, font is small, and you have to zoom in to read a paragraph
… probably the more common experience on the reading system side

Marisa DeMeglio: maybe apply an alternative style sheet when zoom button is pressed

Garth Conboy: take a kid’s book or cookbook, every line is spaced
… browser is not doing the line breaking, and maybe not the character spacing
… if you do something with font…in response to aspect ration
… better way to do FL…rather than
… a lot of manga is FL, but all it is is a jpeg with the art and text squashed into an image
… the antithesis of something accessible

Wendy Reid: this gets to where some of this guidance should go
… in FL content, I see two types; one is image only
… essentially it’s a slide show; image, image; likely no alt text
… may have some navigation; TOC page; mixed bag
… other side is when live text is applied
… have seen solid image background with text over top and media overlays to even background is not a single image
… precisely placed bubbles, captions; get quite a bit of markup for a single page experience
… I have seen books with an entire block of text; to where every letter is wrappted
… get t–h–e–space
… steer people away from that
… no way to make every letter wrapped in a span, will sound or look like someone citing the alphabet to you

Tzviya Siegman: this is a huge accessibility issue, but I don’t look at FL books as a sighted reader; a basic usability issue
… I have to work with a viewport square; look at something square
… even on a tablet, no way to make that book, if trying to duplicate it; the aspect ration becomes destroyed
… or doesn’t work on rectangular devices; difficult to read unless a few words on a page

Dave Cramer: FXL = small print edition

Tzviya Siegman: even if not talking about something being read aloud

Charles LaPierre: Having spans for every character was originally how bee-line reader https://www.beelinereader.com spanned each character so they could have a color gradient so the end of one sentence was the same color on the next line.

Karen Myers: [scribe missed last point]

Garth Conboy: I think Tzviya raises a good point there
… Everything said there is equally applicable to PDF
… a square PDF; pan and zoom, do synthetic spreads to make it better in landscape
… EPUB fixed layout is PDF but done with HTML and CSS
… it’s the same; which is inherently more accessible which is better

Tzviya Siegman: We can approach this as a usability issue not just accessibility, but we solve the usability issues with accessibility

Garth Conboy: Tzviya has disdain for FL; but I love it, especially for kids’ books

Deborah Kaplan: and when fxl epub is not easy to do, people who need fixed just create PDF, which is less accessible and usable.

Garth Conboy: do what PDF does, but still may get horrible results

George Kerscher: part of this mess started when Apple implemented the media overlays before the spec was approved
… they took the fixed layout and media overlays partially implemented and got a good part of the marketshare
… I wonder if we demonstrated media overlays with reflowable content if we could
… demonstrate that as a good product
… that would make it in the European market
… if you have this FL that is not access; and @ that are not media overlays
… you can sell one in Europe and you cannot sell the other
… Wonder if the cookbook people gravitated to fixed layout because they did not know any better

Tzviya Siegman: +1 to George

George Kerscher: I see college text books that are gorgeous and they are all reflow

Marisa DeMeglio: pretty sure that FL….algorithms required…can be difficult to know what page the reading system is on to do the synchronized highlight
… pretty sure that’s why they did it that way
… I believe that Readium and hopefully Thorium
… had a good reflow media overlays implementation; would be a good way to show it
… I think we have 20 Moby Dick’s in reflowable overlays

Garth Conboy: I think George raises an interesting point
… have not seen anything beyond a text book doing overlay
… not doing beyond FL because there is no production content

Gregorio Pellegrino: we have in Italian!

Garth Conboy: for some flavor of content, that would be great to see people building to get people to support it
… substantial majority; a lot is kids’ books
… you are no going to do Dr. Seuss in flowing
… when you need print fidelity
… not use FL when you can do flowing, but there is a lot of content that does not work

Deborah Kaplan: or you can do kids books flowing, but it won’t happen

Ken Jones: I would say Thorium and Colibrio reader are doing good examples of overlays; best readers for that; chicken and egg
… if no reader that supports it
… not nec accessibility
… but possibility of doing things in FL with interactions
… which means, that’s what sets it apart
… from design things you can do
… also do more with page
… and that sort of thing; another differentiator

Wendy Reid: cut in here to add
… talking about parts of the spec that are under utilized
… we really have all the tools at our disposal
… what came up in pub BG and survey
… mixing FL with reflowable
… an under-supported feature by reading systems
… we don’t and it’s cool
… wonder if that could have a huge impact
… when designing page, it could be
… like Dr. Seuss
… could have overlays
… or text or cook book with full bleed photo of food
… and reflowable page so I can read the recipe
… but I still get the full screen images
… wonder if that is a direction to look at; the under-utilized parts of spec
… look at reflow and flowable aspects

Dave Cramer: the lack of uptake of reflowable with synched audio is not just a tech issue, it’s a rights issue
… because audio rights are separate from the print rights

Tzviya Siegman: dauwhe++

Dave Cramer: I have tried to convince my company to combine and offer as single product
… but there are contractual obstacles there

George Kerscher: explain what you mean by this full bleed stuff; can you explain it?
… you have great image, flow text around it; picture of George’s goulash soup

Wendy Reid: thinking about soup
… one thing that happens with reflowable books with image
… even if you set CSS to object fit, you end up with margins, or the image breaks
… if height of image
… depending upon screen size; image might get cut in half

Juan Corona: full bleed = no “columns”, no margin?

Wendy Reid: idea of a full bleed image is make it fit and fill the screen
… like in FL book

George Kerscher: is this an SVG thing

Wendy Reid: could be mixed modality
… I could say image 5 got HXTML
… and definitely alt text in spine
… final item is the

Juan Corona: +100 for mixed modality, full bleed utilization in reflow

George Kerscher: Picture would always be the full page?

Wendy Reid: yes

George Kerscher: I remember many text books where first page would be a full page image and on the right would be the chapter
… and elephant and mouse diving off a diving board…very cool…we need to do that

Wendy Reid: that is possible today within the spec but it is not used widely
… It works in Thorium when I tested it

Dave Cramer: this is a larger issue than fixed layout or reflowable
… balance of power between content author and reading system
… my content is displayed on part of device
… and part of device reserved for the reading system
… I want to take up every inch of screen, which could interfere with user interface
… we are looking for a way…can I take over your screen for a while and it gets complicated

Wendy Reid: don’t think most reading systems would let you do that

Dave Cramer: you don’t want problems with text butting up against margins
… reading system will put margin on body element
… image will still have that margin
… have not done way to communicate the content and to have reading system still work if content obscures device port

Ken Jones: I think part of the dislike of FL in general is that it’s really bad on small screens
… in terms of accessibility if we can have something well structured, reading order, well described
… that would be good for accessibility
… you should not be looking at elephant diving off board on small screen
… Like versions of books for small screens
… and FL for no screens
… and let’s enjoy design aspects of larger screens
… most publishers don’t want to publish books that are basic and not lavishly illustrated
… not just that it looks nice
… if a complex topic
… it helps convey complex information by having a well illustrated…photography and annotation are important

Bill Kasdorf: +1 to Ken

Ken Jones: not look at complex illustrations on devices that don’t support it

Avneesh Singh: one practical application is tables
… reflow text books, but have to put images for the tables because they will not flow
… maybe publishers not aware that you can have table in FL and have text in reflowable
… a practical example that came up
… are we discussing the things
… on this problem, or going out of the track

Gregorio: proposal that Ken did
… having same EPUB with two renditions
… rendition specifications; but now we don’t have it any more
… that is not a born accessible approach, so I don’t like it
… one way for sighted and one for those who have impairments, so I don’t like it so much
… If content creators work hard
… they can make fully accessible fixed layout EPUBs for web apps
… to be fully accessible and so on

Avneesh Singh: just clarification
… for information
… mention for clarification
… European accessibility act requirement of multiple renditions
… how we do @ is a question
… spec in EPUB 3
… thinks it’s somewhere there
… may not be normative
… may be @
… let’s stop here
… EPUB accessibility app with multiple renditions

Bill Kasdorf: to reinforce Ken and Avneesh’s points
… in science, STM, often need for complex diagram or flow chart that cannot be viewed on a small screen
… so you need an alternative way to describe it
… think of an info graphic in NYTimes
… they are geniuses at conveying info in a visual way
… for non-sighted, not make markup do the work
… have to provide content in a separate form with an extended description

Wendy Reid: I do look at those NYTimes infographics on my phone

Tzviya Siegman: you said something I was going to say
… at Wiley we have text books, many types of complicated stuff
… students tell us they are using their phones
… not optimized for desktop; people will use what they want
… we have seen from NYTimes
… good job of making things available
… talking about WCAG 2.1…
… maybe someone from CSS WG can come talk to us on recent developments, and get a crash course on SVG
… not that it’s impossible; may be more difficult
… table rendering is hard anywhere
… if you deliver an HTML table, it is possible to scroll through it

George Kerscher: can we get Gregorio to explain what he said
… about fixed layout that it could be accessible? I did not understand

Gregorio: FL for ebook can be fully accessible
… PDF is problematic

George Kerscher: how does a low vision person get around the need to increase the font size and stop from panning back and forth from reading text

Gregorio: my POV, if you don’t have this text in the page, you can increase the fonts as you want and it reflows some way in the page
… I know we don’t have all the control like PDF, but it can be done; design of page needs to support increase of font size to 200% as WCAG requires

George Kerscher: having a table as a fixed layout
… and zooming in to 200% and panning back and forth
… from a low vision perspective, I would think that’s ok
… as long as body text, you don’t have to do that for the body text
… where reading comprehension and flow matters a lot
… almost like a magnifying glass looking at cell by cell reading rather than a paragraph
… a fl table with reflowable text is something that could work
… Looking at EU requirements with multiple renditions with FL
… I think they are looking at specs from a long time ago
… and our work will impact what they say moving forward
… their requirements are not fixed; they were putting out early thoughts
… not an absolute requirement
… we have opportunities to ‘head them off at the pass’ so to speak

Ken Jones: wonder if we should have a classification of a visual book like we have an audio book
… that it needs to be viewed in a certain way
… audio books are not accessible for people who cannot hear them
… visual book works for those who cannot hear
… cannot have one thing that suits everybody
… if we could we would not be worrying about it ten years after EPUB standard has been around
… not right to say we should not do certain design things because not everyone will benefit
… if not working on a phone, maybe use the audio version
… not dismiss what we get from a visual publication

Wendy Reid: a lot of excellent points have been made here
… coming up on one hour of discussion
… I would like us to come around on some, not resolutions but directions
… I think we have a couple of things we want to look into
… some of the stuff is
… what does this document look like
… Avneesh made a good point that this is likely a separate set of recommendations; a separate document to put together and access
… looks like one area is better
… mixed modalities; fixed and reflowable together
… is a direction that would be positive in this space
… approachable for content authors and reading systems
… and also do investigation into SVG and what we can do around that
… I think Tzviya mentioned
… we talked about CSS as well

Gregorio Pellegrino: viewport? I think it is a big limit for responsive design within EPUBs

Wendy Reid: we could talk about media queries or different CSS modalities
… a lot going on in modern CSS in transforming content based on context
… we have flexbox and grid, almost these programmatic qualities for CSS
… direction is to liaise with CSS and see what they can do for us, or we can be a test ground for more CSS magic of sorts
… Sounds like we have a couple of things to look into
… and this is point where I ask for volunteers to do the research
… I want to work on this
… I did not bring this up to have someone else to do it, but I need help; not my area of expertise

Laura Brady: I am keenly interested in helping on this.

Gregorio Pellegrino: meeeeeeeee

Avneesh Singh: I am not volunteering
… i queued up to say that visual layout
… is extremely important; why people go for FL
… include people who are actually publishing FL, like Japan to make manga accessible
… we should encourage them to join this task force
… I will be happy to discuss with someone from the DAISY team to join this

Tzviya Siegman: I am not volunteering, but I can help with the wrangling

Wendy Reid: we always need a wrangler

Ken Jones: I would like to be involved also
… thinking of my list
… the reading order is at the top of my list
… it is the most important one
… without it, you have something that cannot be understood
… that could be…is Romain on the call
… that could possibly be automated
… content sections, contrast, metadata, is already @
… but the reading order thing, not sure how that would be solved
… in a way to be fixed layout pub would be accessible in that way
… one of those things, i cannot check for everything

Gregorio: you can check level one and two but not the reading order
… we check it manually

George Kerscher: with ACE we do some data visualizations to help with manual testing
… wonder if you could traverse the DOM of a FL
… portion of a page in order to extract the reading order
… and present it not in FL but in reflowable view
… which would give person the info that Ken was looking for, I think
… that would be one approach

Gregorio Pellegrino: there is the accessibility tree

Ken Jones: or a visual overlay on page so you can check the reading order
… you could be proofing; still need human to look at it but a quicker way to see the flow through the page

Romain Deltour: right, tools and visualization can definitely help a human check this

Romain Deltour: you can always start disabling the CSS to check the reading order ;-)

George Kerscher: would that be a visual check? What software would do that? In the authoring tool?

Ken Jones: if it went through a fl of an HTML doc; if that is reading order, a nice visual way to see the flow of the reading order

George Kerscher: if these are features like mixing of FL and reflow, already features in EPUB 3.2
… doesn’t exist, no best practice, maybe this is a CG thing
… to enlist the help of a wider audience

Marisa DeMeglio: when we talk about checking the reading order, is it checking that the TOC and spine are in order?

Ken Jones: reading order

Marisa DeMeglio: doc order may not match reading order
… I’m and ACE developer
… what we do have is an outlines view that I have referred to
… gets into the HTML outline algorithm
… ACE does let you compare…TOC…headings structure; cannot tell you if visual order is in different order than doc layout
… not sure what approach we can take
… maybe look at DOM after applying CSS

Tzviya Siegman: There aren’t automated tools

Wendy Reid: based on my experience, something that is purely manual
… only check you are not putting an H6 above an H1
… only a human knows you put the footer above the main content

Tzviya Siegman: An automated tool can only pick up what’s in the accessibility tree, and if CSS reorganizes things, it’s not in the a11y tree

Dave Cramer: looking at render tree would get complicated

Avneesh Singh: i got a bit lost in this discussion
… hesitating to pick up the CG issue
… but I think I should say what is in mind
… when it’s best practices
… question is what kind of document will it become?
… if a WG note, remember timeline is 1 year, 15 months at most
… if it’s a note, it will be a moving document
… if note in WG, there is a heavy process to maintain it; go through the whole procedure again; processes of evergreen
… a better place for best practices is the community group
… just to keep in mind, don’t have to make a decision now
… may take a while to come up with best practices for fixed layout
… so maybe CG is the better place for this

Bill Kasdorf: apologies if Tzviya already made this point
… pursuing NYTimes is fertile ground as they are members now
… infographis
… sometimes is an entire two-page spread, a very large graphic
… they clearly are providing an alternative form
… what are their techniques, might be worth pursuing as we have them as members now

Wendy Reid: we are getting into the weeds

Karen Myers: +1

Wendy Reid: we have been really productive. Thank you everyone

Garth Conboy: If mixed modality (fixed and flowing) gets traction, I’d be pleased to guilt at least one RS to support it

Romain Deltour: answer tzviya, testing reading order for a11y is difficult
… some tool can be envisioned to help reading order with a11y. but in general it7s difficult
… Adobe recently has some AI tool to add reading order in PDF and make it reflowable

Charles LaPierre: +1 to ACE adding this reading order overlay option :)

Romain Deltour: Even Adobe started to use AI to do so. It means, it’s difficult to achieve in tech

Ken Jones: Thinking if pages can have raw test for reading order and put to RS.

Wendy Reid: seems we have completed our agenda

3. AOB

Wendy Reid: do we have other biz?
… other other biz?
… thank you everyone for coming. We will be cancelling next week WG.

Bill Kasdorf: November 6?

Laura Brady: Thanks for your work chairing this epic meeting, Wend and Dave.

Karen Myers: https://www.w3.org/2020/10/TPAC/breakout-schedule.html

Wendy Reid: next WG meeting Nov 6

Romain Deltour: +1000 @LauraB__, thanks Wendy and Dave!

Tzviya Siegman: https://www.w3.org/2020/10/TPAC/breakout-schedule.html#calendar

Wendy Reid: in Boston timezone