W3C

– DRAFT –
FXL Accessibility Taskforce Meeting 27 June 2023

27 June 2023

Attendees

Present
CircularKen, duga, Gautier, gpellegrino, Hadrien, jamesY, jgriggs, Naomi, SueNeu, wendyreid
Regrets
-
Chair
wendyreid
Scribe
SueNeu

Meeting minutes

Wet's start with the new people to this group

James: I am a production technologies manager

Jeffrey: I'm with Penguin Random House, I'm on the team that does all children's ebooks...

we have a team that deals with accessiblity in ebooks

<wendyreid> w3c/publishingcg#59

Investigating the Use of SVG

Brady: I found a sample epub that doesn't have any copyrighted images, where should I put it

Brady: it might be too big for GitHub if not I'll use Google drive and share a link

Gregorio: If Brady can share the file, I can try it with some assistive technologies..

So we can be sure all of the value chain is ready for this kind of file

Brady: the file has a media overlay, and the ARIA may be bad...

I don't know how to do word/sentance level ARIA...

I don't want to confuse ARIA, so we were leaving the reading of the book to the media overlay...

I don't expect that as it stands this is a wonderful solution, but it worked for content we already had...

Hadrien: What we see with large content, we see nested files like a nested doll...

Any specialized reader will get rid of some of it...

some will get rid of SVG or HTML altogether...

Some reading systems are specialized and won't use SVG

Wendy: I guess that raised the question how to address this issues...

we have a specialized reader that handles fixed layouts

Gregorio: We are trying to find solutions for accessible content, right now fxl doesn't fit that...

we may find ways that work in an education context...

we will publicize them so new creators can use these techniques...

right now software can't export SVG so right now it can't be used...

we are investigating other great stuff...

Hadrien: We need a solution that doesn't rely on SVG & HTML...

And it needs to work on one page and on spreads...

We were thinking of something we call guided navigation...

It involves navigating by fragments...

NOTA has been using a screen by screen solution...

I think if we move that direction we can use existing region-based documentation

<gpellegrino> +1 to multiple solutions :)

for FXL to be successful we will need multiple solutions

Gregorio: on content that is all images, we will need another solution

Wendy: if we are not using HTML or SVG what would we use?

Gregorio: the content for comics is bitmapped. To reference fragments we reference...

fragments in multiple shapes on each page...

There is speculation that this could work in SNIL...

There are people exploring this space...

Is it best to start with Navigation? JSON?...

We care more that people can create an experience...

Guided navigation may not necessarily follow the spine...

We think there are alot of similarities between media overlays and guided navigation

Wendy: how would this be implemented?

<wendyreid> https://idpf.org/epub/renditions/region-nav/

Hadrien: this could be authored or automated...

We see reading systems that can do this on the fly like Apple...

There are/will be tools for creators to do this...

Gregorio: remember when you did a matrix of different types of publications?...

perhaps we could post that in a wiki so we can look for different solutions for different spaces...

to complete the matrix

Wendy: agreed

Ken: I did a talk about region navigation, and I have a sample that is already...

a valid Epub3, and has some support from a reader....

At the moment it is not tied in with media overlays but it could be...

what do we need to have a different file type...

to broaden away from HTML

Wendy: This has been an issue in the EPUB system...

that there are reading systems that strip out the HTML...

I will reach out to the Japanese because they are at the forefront of this...

Ken: If you have a folder of audio files we can serve them up in order but we need more structiure

Hadrien: I think removing HTML for those reading systems is not necessary...

they use whatever is native to the platform to create a good reading experience...

they are not going to use HTML or SVG to do what they have been doing for years..

based on bitmaps...

I don't know if we need another format...

Maybe we could use SMIL more extensively or another way to use what we have...

Brady: I

'd like to caution against throwing away the containers we have developed...

we had a case where the reading order changed and the cover didn't display correctly...

I know we're not saying we're getting rid of epub, but we might consider keeping metadata containers..

Wendy: the EPUB maintenance group is responsible for maintaining the spec for audio etc...

I know the community needs guidance right now about accessible epubs...

we can be exploratoratory, its OK for us to suggest things outside of epub...

Hadrien: You are right pointing out that epub is good for communicating metadata and an explicit reading order...

It does require HTML and SVG...

Maybe we can retain all the interesting bits without all the annoying bits...

<wendyreid> w3c/publishingcg#60

Wendy: We can all argee that metadata and structure are non-negotiable, but the wrapper is negotiable

Text size and font adjustment

Wendy: thank you to Gautier for listing all the ways we could do it...

Wendy: How do we get text into fixed layout and make it an experience for everyone?

Hadrien: I think this will be the most challenging...

If you have text within or that can be extracted from the content...

without affecting the layout...

I don't buy into super complex files...

<gpellegrino> +1 one to RS approach

we need to let reading systems choose one or the other...

Wendy: How do we best signal to a reading system it should do this

Ken: Mainly you need, section, order, and image descriptions...

if you have these in place in an FXL...

If we can do this things...

Using CSS I was able to discard the

This is much neater than a complex file...

maybe we could use media queries...

Gregorio: I agree with Ken and Hadrien...

At least for HTML FXL publications we may provide guidance...

for what to do with HTML so reading systems can access it in a different way..

the tricky part may be how to join two spreads...

it can be done

Wendy: I wonder if when you get into complex text books...

the page layout vs content...

If make these a reflowable, how do we maintain relationship between important images and text

James: it depends on the publication...

We move the images to a more logical location...

close to their original point of discussion...

the highschool market or k-12 does focus on precise layout to grab the reader...

that is a lot more difficult...

it really does require fixed layout...

Gregorio: we all images are put in the flow of the text, images without alt text are not

Naomi: People who can easily make reflowable versions should be encouraged to make reflowable books in the first place...

We can focus on publications that can't be made easily reflowable...

and look at solutions like reflowable containers within a reflowable ebook...

so the text is still in context with the rest of the layout...

the closest existing mechanism is how reading systems display footnotes...

as a popup that can be dismissed...

maybe we can eventually develop tagging that lets reading systems build that overlay or not...

Hadrien: we have an API in Readium that breaks down the content into smaller pieces and iterate...

If an FXL is well designed you could use this API to create a reflowable equivalent...

Like browser reader mode...

the main issue is spreads...

we don't have any way to convey information across spreads...

if you have structural elements that cover both it is impossible to display them...

the existence of spreads will limit what we can do...

Ken: Part of the recommendations may be workflow or design recommendations...

if you put an image as the background in html...

you can put the more important images in the content...

Brady: 100% of this content was originally a paper book...

you can tell the publisher that they have to change complex layouts...

but they're not going to do that...

This sounds similar to our bubble zoom, but instead of images...

you could adjust the text, contrast, improved screen reader...

we could approach this will region nav...

bubble zoom would work with text that is small...

Naomi: while we can't tell people what they can do...

we can suggest that layouts without a logical reading order we can suggest...

that this is inaccessible, here is a potential solution...

Hadrien: that is a good solution, but a solution with a compromize...

I think it is worth mentioning...

we could suggest region navigation that could work across spreads...

some of the semantics will be omitted but the reading order will be right...

it might not be best for screen readers

<wendyreid> w3c/publishingcg#63

Wendy: focus: Describe what is an accessible fixed layout epub

Wendy: for the next meeting next time I'll try to have that matrix...

we can discuss what approach works for which kind of content...

Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).

Diagnostics

Succeeded: s/[replace-me]/guided navigation

Succeeded: s/Gregorio/Hadrien/

Succeeded: s/SNIL/SMIL

No scribenick or scribe found. Guessed: SueNeu

Maybe present: Brady, Gregorio, James, Jeffrey, Ken, Wendy

All speakers: Brady, Gregorio, Hadrien, James, Jeffrey, Ken, Naomi, Wendy

Active on IRC: CircularKen, duga, Gautier, gpellegrino, Hadrien, jamesY, jgriggs, Naomi, SueNeu, wendyreid