Meeting minutes
wendyreid: Welcome, agenda review
ivan: We made a mistake last week on the 3.4 draft, we forgot some notes that have to be republished
<ivan> Proposal: publish a new note entitled “EPUB Accessibility Techniques 1.1.1” and “EPUB 3 Overview”, with short names “epub-a11y-tech-111” and “epub-overview-34”, respectively, which will supersede the similar 1.1, respectively “3.3” versions of these note.
ivan: we have a couple of notes that are bound to versions, so we have to publish drafts of those
<Avneesh> +1
<shiestyle> +1
ivan: so we need a resolution
<duga> +1
<gautierchomel> +1
<sue-neu> +1
<wendyreid> +1
<ivan> +1
<toshiakikoike> +1
<MasakazuKitahara> +1
<gpellegrino> +1
<rdeltour> +1
George: Can this be modified after we publish?
<George> +1
ivan: Yes. The old ones are now frozen to 3.3, all new work happens in the new ones bound to 3.4
RESOLUTION: publish a new note entitled “EPUB Accessibility Techniques 1.1.1” and “EPUB 3 Overview”, with short names “epub-a11y-tech-111” and “epub-overview-34”, respectively, which will supersede the similar 1.1, respectively “3.3” versions of these note.
Footnotes, Extended Descriptions
wendyreid: We need a better name for this, but we will discuss footnotes/extended descriptions
gpellegrino: Last time we proposed to have a longer list of elements
… there are several
… many are for publisher guidance, but no impact on RS implementation
… so those are out of scope
… but some need both
… one is cover, or perhaps fit-width images generally
… commercial pages is another (may need to ensure it is shown in samples)
… then poetry
… and linear/non-linear items
… and finally css page break property
<sue-neu> +1
ivan: I want to understand, for instance the page-break property - there is a spec
… linear/non-linear
… what else do we need to say?
… and which spec? a11y? rs?
duga: I think the problem in CSS page-break
… is that its challenging, it was almost removed until we asked them not to
… the spec is very vague, easy to do nothing and be compliant
… "avoid" is flimsy, elements it applies to is strange, only to block-level elements, its hard to tell what to do
… it's left up to the implementer
… and what happens in the reader, especially in scrolling contexts
… linear/non-linear is intentionally vague
gpellegrino: I think this all at a level of guidance and notes
… but having guidance is useful
… We have guidance like this in DAISY knwledge base, but only for authors
George: Add endnotes to the list
… We find they are supported when in the file, not when in another file
wendyreid: Page break is one that I noted as important. I also added dpub aria and RS behavior (e.g. how to use it in RS)
Avneesh: DAISY board approved a RS requirements group under DAISY
… we are defining all these things under that group
… It is a little beyond mainstream, since it is a11y focused
Hadrien: Back to page breaks, historically we had specialized properties
… One problem we have is that we don't really use CSS page break model
… so this doesn't integrate well
… we had this because there was a point in time where we had specialized renderers, but that is no longer true
… I see the use case, but there is a disconnect between this and reading system behavior
sue-neu: The page break property, I work on books for younger readers
… Sometimes I need an image and text together
… so I need a way to keep things grouped
… so I would love to keep that together
ivan: I would like to understand where we are going
… endnotes, footnotes, they are all problematic
… There are guideline for authors and RS, but I have no idea what we would have to change in the specs
… So if we go down guidelines, then the DAISY work makes more sense. If they are doing it we should cooperate with them to avoid duplication of labor
… But first we have to decide what we want
wendyreid: The question we have is where to do this (spec or elswhere)
… and the answer seems to be somewhere else
… This feels more like a techniques document
… One thing we can and should include is a test suite
… So we you can check for support in RSes
gpellegrino: I agree
… to reply to Ivan, it is a little different in pub than web
… In web you can control the UX
… in epub, there isn't really JS support and more things are declarative
… we rely on RS to display the content
… so we should agree among the parties on how to display this
… for instance we gave guidance to Adobe on how to handle certain things
… And they asked if this was correct or not, we said to just trust us. It worked out
George: There is a relationship between the RS and the content where if you can depend on the way a RS will work
… So right now we use backlinks from endnotes, but there are other types of links
… And some RS can handle go back from them, but we are putting in backlinks which is bad. It would be better if we could depend on the RS to maintain a backstack
Hadrien: I think it is a tricky topic, existing implementation can guide us
… for instance lack of footnote use not being used in Japan is a big deal
… and needs to be fixed
… The RSes need to fix this
… There are some things we can do in readium and thorium
… for instance, we will handle endnotes that are in another document
… Go back is good, but popup footnotes are useful
… But they tend to be in plain text
… it would be nice to use some other affordance like a sidebar that properly display the styled html
… But this should be a pref
… We can never be one size fits all for this, so we will probably do all three
… of course this only applies to us and anyone that uses us
… It is hard to see how the wg addresses this
ivan: So I stubbornly come back to procedural side
… I see 2 docs, guidelines for authors, and another for RSes
… in both cases, adding test cases and adding it to our test suite is a great idea
… but this is significant work
… So if we pass this as a resolution we need to assign editors and people who will lead the effort
… this can't go to me and Matt
… if we can't find someone to do that then we should close the issue
sue-neu: To build on that, we should also consider that this is not a document we can do one and done. It will need to be updated as we go along
shiestyle: Popup foot notes are hardly used in Japan, but if have long text for a11y we have to find a way to do this (e.g. extended desc for imaages)
… If it is easy to find a suitable approach it is fine in Japan
duga: Footnotes, there is some real guidance we need to give to handle it properly, it's very inconsistent right now, it's helpful to have authoring guidance
… you need to guess what happens when you encounter a link
… the sidebar idea, what if multiple footnotes, can you show them all
wendyreid: we do need people to work in this
… it is also really important, so it is hard to accept that we might not have someone to do this
… And to what sue-neu said, things don't change too fast
… so the more confidence you have that something is a link to a footnote, the better
George: One of the other things that looks like a footnote but isn't, is an annotation
… specifically author provided annotations
… Do we ignore this and just call it a footnote?
… for instance the anmoted Alice
Hadrien: There is also the affordance for tap or double tap interact with an image
… and another is tables
… image is often implemented, but there is a lot to explore (e.g. extended desc)
… But tables is a big one and why people really like PDF
… It would be really nice to have a good implementation
Avneesh: On to the work management side, one thing the a11y TF can do is create an index for these topics
… Since it is all the same people who are also working on the knowledge base
… so a11y TF can at least take that up
wendyreid: That is a good first step. Maybe we can take that info and go from there
… anything else we want to include or are missing?
George: Do these impact dpub aria? do we need new roles?
Avneesh: Yes, and this will help us identify it
George: Some question about JAWS and NVDA and how it interacts and fits into the RS side of things
Avneesh: Those are things that are going on and will continue to
… This is where the index will guide what we are working
… on. It is hard to create a plan at this stage
… There is ongoing work that will go on for 5 or 10 years
George: We have core media types, do we have the same concepts for behaviors?
all: no
CharlesL: Back when the diagram center was around, someone from Norton created a plug in that would, for images, grab info (extended desc, etc)
… So when you hover you would get info
… he made an API for that, I am not sure what happened to that work
… this might be similar to what Hadrien mentioned
Hadrien: It is very similar
… I was thinking a view where you could interact with the image along with desc
Hadrien: so the general concept is the RS would have affordances over fragments of the doc
… but it is hard if you also have JS
… so really hard with fixed layout with JS
… so if there is JS, we will probably disable them
… except maybe side panel or something like that
ivan: I don't know if the presentation we just saw from CharlesL was JS based
Avneesh: Yes it was
ivan: We said we need to go to html, I have the feeling that the aversion to JS can't last for long
… so I know it is allowed, but we also say don't do it
… I don't think long term that is an option
… I think we need some ways to do this programmatically
… That tendancy is there and people will be less and less interested in declarative
… so we need to allow it on the RS saide
George: There is a lot going on with visualizations so I kind of agree with Ivan
… Also being able to hold things together might be a thing for dpub aria
duga: You can do that with page-break: avoid
… page break is not a great way of doing anything
… it's remarkably expensive to get that info from the DOM
… I had a regex to check if page-break was used in a file, when its present it has a cost to rendering
… to Ivan's side, we had a spec for that
… what if you wanted to do interesting data viz in reflow, widgets
… it was never used, no one wanted to figure out the widget spec
… my feeling is, you might be right, but then EPUB is dead, all publications are now web pages
… the web is a development platform for applications, once EPUB readers become hosts for applications, it makes no sense, browsers are already very good at that
… I have no interest in recreating web browsers
… publishers don't want to write applications
… if you want advanced things, do it on the web, but for straightforward content, use EPUB
Hadrien: I wanted to say more on that
… I hve had to deal with epub files, where each file was a react app
… so I know what it takes to do that
… I think there is some value in consistency in affordances
… that might not be available otherwise
… there is also desire to do your own thing that won't be a problem
… The way we handled this with fixed layout and JS was to do as little as possible
… So you are left with the spine and toc, and that's about it
… we could do that for reflow
… we would drop pagination
… and maybe add some affordances
… some thing would be hard
… bookmarks maybe but annotations are hard
… so we may have to do that
… The people who want to do that don't like containers
… So remote resources come up and are problematic
… it is intersesting to explore
… there are some things you gain, some you lose
… I am not sure if users will be happy with lack of consistency
sue-neu: I agree with ivan that one reason we don't pull in younger people is lack of scripting
… But I really hate the idea that epub is dead, as we have a lot of them
wendyreid: next steps, a11y TF will create an index
Dark Mode
duga: [shares screen]
… I noticed this a while ago when we implemented dark mode in the specs
… the web has caught on to the fact that people like to read in different colour modes
… we've had it in ebooks for 30+ years
… the web has caught up!
… reading systems often have 2+ modes
… this interacts oddly with the platform you are on
… if your platform is on dark mode, you may not want to read that way, the RS will override
… CSS has this cool way of making the web page adapt to the mode of the device
… [sample on screen]
… you can specify different CSS for light mode or dark mode
… RS do strange things to make colours work
… Play books has light, dark, sepia, and nightlight, this is mapped to different activities
… depends on the device, on Android, the activity can be light or dark, and the web view will pick up the activity, similar on iOS, no idea what happens on windows
… since this is automatic, the webview is extracting these styles and implementing them
… tried this sample on several platforms
… to see what would happen
… what happens is, if you are in anything other than light mode, these styles are ignored for colours, discarded, no issues
… in light mode/neutral mode, they are ignored or follow the setting of the current view. The colours might get mixed, or the device overrides to dark mode.
… only affects light/neutral mode
… doesn't apply in dark mode
… it's horribly inconsistent, no issues today but might be an issue in future, we might want to warn publishers
gpellegrino: EPUB is dead, the way RS managed this for years was problematic for a11y, if the content creator used colours, it would get messed up when the themes were added
… colours would switch improperly, I'm not sure we should suggest not to use
… using media queries we can learn about specific colours or modes for a11y
… maybe we should require RS to use the browser method, and if the EPUB creator does not declare, the RS can apply their stylesheet
… if the EPUB creator declares, the RS should listen
duga: The problem with that, EPUB ecosystem is much richer than web, people have been reading long form contnet for a long time
… it's all over the place on different platforms
gpellegrino: You can still offer sepia, if the EPUB creator provides dark or light, you should honour that
duga: What about charcoal, Kobo has that + dark mode
… Thorium doesn't have light, it has neutral
… CSS doesn't mandate names
… we could make a list
… my reason for not going down that road, figuring out all the variations is challenging
Hadrien: I don't see how this could work
… just assessing the presence of these things would be hell
… the only place this could work is FXL
… reflowable is "whatever I want", many apps let you set all the colours
… I don't believe that author intent can be preserved in this
… FXL is different because the relationship with RS and content is different
… only thing RS might do with FXL is spread layout or zooming
… doing this in FXL would be fine, but in reflow it opens a huge can of wor,s
… incredibly difficult to implement without breaking expected behaviour
ivan: I am more with Gregorio on this, if I am an author take the responsibility to use the CSS and declare colours,
… that is a request to the RS to hand off the settign
… I set up these things
… that does not seem related to the FXL thing
… I don't see the problem with that
duga: You don't do UX for reading systems
… RS implementors are horrified
gautierchomel_: The question raised by Gregorio, and the accessibility part, we're not asking to have author style maintained in reflow
… the point is to provide a mode accessible RX in some modes, that some RS can't handle right now
… I agree with Ivan, if the EPUB creator makes a mistake, the responsibility falls to them, it should be used wisely
… it's an accessibility problem
… some content becomes unreadable when the colour is changed, but some experts know how
duga: As a reader of books, I would argue you have no idea how I want to read
… you create light and dark mode, as a signal to the reading system, it's not trivial to detect but possible
… my device is in dark mode 100% of the time, and 100% of the time I read in light mode
… in Ivan's scenario, the CSS would follow the system settings
… I need to then switch my system settings to light, to read in the way I want
… I will then find a reader that does not do this
… I will post a one-star review of the app I'm using, and use another potentially bad app
wendyreid: I see both sides
… however as RS implementor and a11y person
… I think it is terrible to move this to content creator
… as it pulls the ability away from me to do what I need to
… I think we have a real problem with styling for modes
… I think that is a real problem, but this isn't a solution to that
… publishers would have trouble doing this at scale
… Publishers often don't test in all these environments
… and the style sheets are so complex any attemptt to figure it out will break some other book
… I don't know the solution though
Hadrien: I completely agree with the two last people, if this were to happen, RSs would go nuclear
… process files, remove all this, break things in the process
… people will say your ebook reader is broken, platforms will need to get rid of this
… it doesn't deal with a problem at all
… no issues with light mode, dark mode is challenging, and then we have the others
… reading systems doing their best to make colours work
… some RS let users select font and background-color
… solutions are likely more along those sides than authoring
CharlesL: This is how I envision how this might work
… me as a user, I hate when I set my system into dark mode and the app I open is in light mode
… what I would expect is for the RS to check my settings, go to the default, and if you change in the RX settings to another thing, that setting gets preserved
… the other part where the author decided to do their own light-mode or dark mode, the RX could be intelligent enough to say there is an alternative, offer it within the settings
… let the user pick that mode as an option, instead of forcing it
… let them choose what the author has provided
gpellegrino: I think that one approach may be similar to the one for font faces
… the RS displays the fonts provided by the publishers, and offers other options
… initial option to honour the publisher default, then switch to user settings
gautierchomel_: I see the same solution as gpellegrino, before we had a lot of normalization of CSS, now we have customize text formatting
… these principles could apply to this too
… to me it's not about the text/background, the issues are more when there are SVGs with transparent backgrounds, how can we set
ivan: My experience, I have played with drawings, combined with dark/light
… when I have a book I have had challenges with images, usually what happens is the image continues to be displayed on a white background, not pleasant
… it's difficult to set it up, there's tools that can produce SVGs with dark/light mode
… with JPG I have no idea
… even there, the CSS which does the recommendation for images, it artificially sets the background to white, I explicitly say the background is neutral
… I should be able to do it in EPUB
… in general, the approach is ignoring CSS color-scheme, I can't adapt my drawings to what is happening in the RS
duga: Start with Charles, what you said is very logical, reasonable, unfortunately users are not logical or make perfect sense
… we've done this, we used to default to the system setting
… Android decided dark mode is awesome, so we followed system, system was now in dark mode, the usero pened the book and it was in dark mode, they were confused, not knowing that there are options
… many users don't use settings
… no idea they can switch colour mode, now you pop up a dialog box, ask them a question and give them a tutorial
… they ignore the tutorial, they're mad at you, people think their books are broken
… to Ivan's point, for images in SVG it's hard to do the right thing, there is logic to figure it out
… it would be great to figure that out
… as Wendy said, media queries isn't the solution
… for sepia, what do we do then?
… white on black, black on white?
… ok so for this book I won't show sepia
… publishers follow suit, but now those books from that whole publisher can't be read in sepia
… users are mad, they can't read how they want
… as RS implementors, users are more important that what the publishers want
… I do want an answer to this problem
… there is a more complicated answer, this might be part.
shiestyle: Publishers don't want more cost
Hadrien: System defaults, I tried in the past, different themes for the app itself
… not for reading
… when there is a big change in the app or OS
… you might want to preserve the default, changing stuff on behalf of users is the biggest issue
… some RS have options per book vs global options
ivan: Browsers do this
Hadrien: I'd like to have something that works, it's not going to work with every single colour theme
… allow an interaction where it's an image, maybe let them open in another view, open the image on its own
ivan: What if the image refers into the content?
Hadrien: Lots of apps do nothing for bitmaps
… we've tried inversion and such
… we leave the image as is, it's ugly, but not broken
Digital Comics (Technical Discussion)
shiestyle: I would like to ear more opinions from the japanese industry on yesterday discussion.
shiestyle: for today let's talk about needs and ways to adress them.
Hadrien: the solution is probably in the middle of images in a zip vs epub completly. We need reading order, reading direction, metadata, cover, TOC and spread placement. Image map approach, visual TOC may be interesting too.
Hadrien: instead, some controls like orientation are probably ot a good idea, it should remain in power of users.
Hadrien: chapters, episodes, volumes, that's issues to deal with.
wendyreid: have we done a gap analysis on metadata? I mean more extended than only for comics. It could help. The more we can hand to the reading system, the more constraint we have in authoring but also the maore liberty we give to the RS and therefore the user.
gpellegrino: I did and found several missing metadata, but the group decision was to not overload content becuase they are not used by RS. We decided to keep them in ONIX only
ivan: be carrefull to not reinvent the wheel. There is probably palces to find those metadatas defined somewhere. EPUB and publication manifest are flexible in that way. we don't define dc terms, we refer and use them.
tzviya: it was 2017 i guess, with gregorio and matt, we created a poll to detremine what was actually really used. We probably don't have to do it again, things have not changed probably
Hadrien: schema.org has extension for comics, we could use it. But we also need to tell people how to use it. There are uses for archive, so we need to be able to use those metadatas in packages.
shiestyle: in Japan some RS have two rendering engines aside, one for fixed and one for reflow. Webtoons are usually fixed.
Hadrien: Kindle asks to identify comics, same in Japan. This is used to excract images out of XHTML files. It is used, we should explore and discuss further how to inform that in the file.
wendyreid: there are usecases where ONIX is not suficiently used or we can difficulty rely on it. I agree a file level metadata is stronger for content ingestion. Sometime in a same serie, the files are done very differently. It's fragile to work with what we actually have.
Hadrien: other topic is spread position, sometime it is important to insurce understanding of the content. We see publishers who gives no information, expecting the first resource displayed on it's own that is not a spec define comportement. We should explore and define better the spread position spec. Maybe it is not only about comics and has to go to the wider group.
sue-neu: I agree it's a fixed layout wide problem, not only comics.
sue-neu: I have real life exemples to show.
sue-neu: we should dig into real life practices.
Hadrien: Also we have the question about accessibility. I thik that fragment level is the place to adress that. We are missing hability to syncronise image fragments with something else, being text or audio, whatever. We have production exemple of capacity to automate a script for a page, but no real way to bring thta to end users now.
duga: the cover placement is predictable; left right placement can end up a mess, we had to ignore publishers information in many cases; we spent time implementing bubble zoom, it was not really used, it was compatible with region based navigation. Might be an interesting starting point. It has been in the mind of EPUB since a long time.
https://
<Makoto> Even if we provide text for every rasterized text in manga, it will not be really accessible. Manga is more complicated than that.
shiestyle: it is not today realistic for publishers to prepare textual version for a complete comics. It's a different version. Audiobook would better respond this need we think.
<sue-neu> LINK preparing comics for Kindle https://
<Makoto> Creating radio drama or novels from manga is a better approach for making manga accessible.
Hadrien: it's true, for now it's too costly, but under marrakech treaty, organisations are doing adaptations, they start to move from Daisy to EPUB. They should be able to do this with that format.
<sue-neu> LINK Amazon aquires comixology and their tech https://
wendyreid: we need to think accessibility not only for blind users. We need more than just a textual alternative, to adress more needs. Region based navigation is the good idea, but is complex to implement today. Audio is not sufficient, but the amount of work involved in audio production could benefit to more users if it was mapped to fragments of images.
gpellegrino: EU act states those contents "should be made as accessible as possible to the state of the art"
sue-neu: using AI to author this way, we must consider possible copyright issues.
Hadrien: there is space to incubate with specialised libraries which benefit of marrakech treaty..
shiestyle: as a publisher it is hard to provide also good pronounciation for TTS. That's a reason why audiobook is prefered. Technologies evolves, we are happy to explore more paths today.
shiestyle: I'll be happy to discuss that further with Japanese publishers to draw a path.
ivan: on a practical level, i would like to have a more active participation from people, as PR, so we can discuss on concrete. The documents are big and I don't want to overload editor's work, we should focus on rewieving.
gautierchomel: Part of the discussion about incubation, which can happen in the CG
… happy to open up a discussion there
FXL Accessibility
Wendy: the TF has been working on the techniques document
… with specific models and examples
Wendy: we don't need to discuss techniques until there is more work done
… we can discuss here some of the ideas being incubated
… since right now we cannot make FXL accessibility fully conformant
… there are ways around this with new tech
… it would be better for us to be specific and clear about what we suggest
… to avoid chaos on the rs side
… especially in converting or mixing fxl and reflow content
… there is a lack of implementation and clarity for RS
Hadrien: we are planning to implement that feature
… our current plan aims for starting work between August and October
… beginning with web first with side by side views
… and smaller views on mobile
… we need to identify fxl books where this will work well
… we will offer this for all cases
… if we are happy with the web implementation we will move on to other platforms
gpellegrino: are you going to document the way this works for content creators?
Hadrien: this is all open source
… there are two parts, how do we create reflowable view from existing content
… and how do we create affordances
Hadrien: this work will be done before readaloud
… we will make a limited set of affordances that can grow in the future
wendyreid: we are writing the implementation document because of things that happen in text in fxl
… multiple spans, curved type
… in the guidelines we ask that publishers not do these things
… it sounds easy to pull the text from fxl to reflow, but it is complex
gautierchomel: we will be doing the same work as a screen reader is doing
… we will find things going forward that we will seek community feedback
<wendyreid> https://
Hadrien: I don't think we will be preserving any styling
<gpellegrino> Accessible Name and Description Computation 1.1: https://
Hadrien: for reflow a lot of it is breaking down content into utterances
… I could have a sentance that starts of one html document and ends on another
… we may have to go beyond existing boundaries
… we will be tempted to treat it like a giant blob of text and try to find sentences
… we might actually be able to detect text out of order using this method
… we don't care about some tags, like span
… unless it is used to specify another language
… there will be a lot of things to consider
wendyreid: a big takeaway will be making a list of things not to do
… we will learn what is catastrophic to get around
… if you can solve reading order, accessibility companies would find this valuable
… it would be cool to have a reading order tool
Hadrien: this would also be useful for language detection
CharlesL1: Benetech is working with Amazon publishing
… we have certified their publishing reflowable workflow
… now we are working on their fxl workflow
… we think it is possible to get to the 2A or AA
marisa: Is there anywhere available of bad fxl?
… any examples we can share of what we are trying to fix
ivan: we should look at our test cases
wendyreid: those are too simple
… it is hard to see bad fxl, they usually look beautifu
… publishers don't like when we pull their content for this
… but we could probably recreate a file with common issues
marisa: it would be really helpful
George: in Acrobat, they now have a reflow option
… duff johnson brought that to our attention
… but in epubtest.org we should be testing fxl layout and reading systems performance
… we have not engaged with this and have no test book yet
… we have been asked to explore this
wendyreid: it is tricky to check these books, in some cases because ai can detect and read text
CharlesL1: a random selection of bookshare books came up with some examples of
… blank html pages with full images specified in css
… and with letters in random order
Dale_R: the reading order issue, would the tab index attribute be a good answer?
wendyreid: yes, but this isn't recommended
Dale_R: if things are visually all over the page, it can be a challenge with the DOM
George: if people follow our guidelines and techniques, and the RS can provide a good experience
… then could metadata be used by the publisher to make a claim about fxl accessibility?
gpelligrino: It is always tricky to say an FXL is accessible
… perhaps we can say it has particular features
George: with visual adjustments, if the content isn't designed for reflow,
… and the reading system provides the reflow
… it might provide the accommodation
wendyreid: about visual adjustments in particular
… there needs to be things in the file to make them possible
… but the reading system decides if that is possible
… its not the book itself that should support visual adjustments, but the reading system itself
… if content can be altered from fxl, do we need a metadata flag to say it is possible?
George: it has to be a combination of the RS and the publisher
… we should be able to tell people that they could have a pretty good reading experience with this
… it is informative to the end user when they decide what tools they will read with
marisa: what is the relation between accessibility document and the FXL accessibiltiy note?
wendreid: the community note offers additional information beyond the accessibility spec
Hadrien: about visual adjustment of fixed layout, when you test apps
… sometimes they talk about things related to the publication and sometimes the RS
… for dispaly guide we focused on the publication itself
… we would probably be looking for accessibility sufficient plus reading order
… and we could provide a mode that allowed visual adjustment
gautierchomel: the way we get to the reflowing feature
… we should specify the alternative rendering, a visual way of providing a non-visual experience
… we are trying to find the right vocabulary, we usually refer to it negatively
… we know some people are looking for fxl content
… we may have to rethink the vocabulary around non-visual reading
CharlesL1: here is an example of a cookbook
… visually the ingredients are on the left visually but they are at the bottom of the html document
<wendyreid> group: [collective disbelief]
CharlesL1: they are at the end
duga: if you allow words to wrap, they can wrap wrong if the font changes
gpelligrino: even from machine to machine the font can vary
Dale_R: if I put a cartoon panel on an fxl page
… for sighted readers the reading order will be self-explanitory
… if I put the DOM elements on the page in the right order, but then
… use CSS to make it invisible, will the reading system still read it?
<wendyreid> https://
wendyreid: it depends on which CSS you use
Hadrien: I have an example to test for that
… it works with screen readers, but you don't always have the TTS feature
enabled on fxl because most people will expect it to be terrible
duga: I see that alot, it is easier to not have to draw the text
wendreid: the biggest takeaway, we eagerly await readium features and the task force techniques document
AOB
<wendyreid> [resounding silence]
George: Are there any thoughts on epub test and fixed layout
marisa: We woud like to know what we are testing
… We would want to start with a good example, then test on the RS to see if it works in the recommended way
wendyreid: I think the for FL test, I think we could make an FL version of the existing flowing books
… It's good to know if the basic things work in FL
… There is nothing in FL that you can't do in reflow
<ivan> List of current tests and report: https://
sue-neu: I am writing a blog post on our 3.4 initiatives
… I want to make sure I hit all the hightlights
… any ideas on what I should cover? What is a good list from all the task forces
wendyreid: You can look at the minutes, and maybe mention the f2f
ivan: Minutes should be ready next week
sue-neu: For the comics TF, I have scrolling, some a11y talk but that is basically the same as fxl
… what kind of use cases are coming up for annotations?
ivan: Edu, legal
wendyreid: export and management
ivan: science as well, scholarly in general
… that is enough for the blog post
ivan: What about html? Should we mention that?
sue-neu: I wasn't there for that, I will just say html vs xhtml
ivan: Yes, just say we discussed it again
CharlesL1: Ivan, do you know what the zoom is like there? It is amazing!
ivan: Send an email to the system team with a note of congrats
… they will like it
wendyreid: Ok, if that is all then we are done!
… thanks for an amazing f2f, good discussion, a lot to do still