Meeting minutes
<wendyreid> date: 2024-11-19
wendyreid: we have three point to discuss. First is the PR and comments received by APA and others. Second is to write the techniques. Third is to incubate features we've talked about that is now possible because we are discussing a new charter.
<wendyreid> w3c/
First. We received feedback from APA, I tried to adress them in this PR. It was a concern about the title and confusions about reading order. We were missing details and reference for a large audience (not EPUB experts).
gautierchomel: To me the main problem with the document, it might need to be split into two or three documents
… part of the document is about guidance for reading systems
… and the other part is about authors
… split part 5 into a separate document
… the section on RS guidance will also be impacted by incubation on new technologies
… secondly, I think that to simplify further use, we should separate what is related to programmatic accessibility, like reading order
… everything that will help us make reflow versions of FXL
… and everything that addresses assistive technologies, and everything related to design
… for someone who wants to make FXL accessible they should follow the programmatic parts, then if they want to make it more inclusive to other disabilities, look at visual presentation
wendyreid: I would like to keep them in this document for now. Maybe reordering with Programmatic / Visual super sections. Because I feel it lacks of maturity to be splitted now.
JonasLillqvist: I tink it has a value to have both in one document (programmatic and visual) instead of dealing with two documents. I agree to separate them better in the same document.
gautierchomel: I am suggesting we split because there are different audiences
… we like to have everything in one document, but when showing to publishers, they focus on the visual aspects, the production team will want to focus on the programmatic parts
… two main sections for now, and wait for more maturity before splitting?
… we need to think about who will be using this document aside from the accessibility experts
CharlesL: strange view from the diff.
CircularKen: It's not bad to me to have one document for different audiences. Splitting section 2 would do for me.
wendyreid: right, I can take that action, spliting section 2.
CharlesL: did we solved the issue about accross the fold contents?
wendyreid: we adress it with a recomandation, but we cannot say "solved", in a programmatical way.
gautierchomel: One other point, the abstract should address two points
… first what APA and others found difficult to understand was what was an accessible FXL, which was explained in the overview
… bring this line into the abstract
… we should also explain the structure of the document in the abstract as well
wendyreid:
Next topic: Technique document
wendyreid: the technique document squeleton is here : https://
wendyreid: structure should stay the same. There's more work to do.
<CharlesL> We need to update the name to include "Best Practices" as well I would think.
Hadrien: a common issue is content breaked down in pieces of sentences. We should cover it. (i.e. span soup)
CircularKen: we should state that span used for text position should not be considered when rendering a fixed layout in an accessible view. They have no semantic attached.
Hadrien: with span soup, there is also often a lack of structure.
wendyreid: other challenge is that some AT insert spaces when meet a span
CircularKen: is the screen reader interp^reting spans? We should explain them not to do it.
CircularKen: span come from indesign. lack of structure come from missing authoring good practices.
gautierchomel: We need to potentially have another documents to address the techniques for reading systems
… techniques for authors, techniques for reading systems, what should they do
… today we have FXL with lack of structure, tons of problems, many reading systems don't display them in reflow, but you can have it with PDF
… same with AT, today they display something, braille, audio, no rules exist for that
… whole topic in itself
… to build guidelines for reading system display
… inclusive of assistive technologies, to explain what they should do when they encounter book elements
… what to do when encountering things like spans
… whole work of defining things
… different from providing techniques for authoring
Hadrien: back on the impact of span, screen reader is a black box, documenting what they do is usefull. On the otherside, TTS is underdefined now. What TTS does is extracting a strcuture and make decisions about tags and semantics. This is the unwriten spec that will also lead the reflow display.
Hadrien: It's probably not the realm of FXL but a wider spec.
wendyreid: that's the incubation work to be done.
wendyreid: we can explore what screen readers do with spans and other tags.
<CharlesL> q_
CharlesL: when we find issues, would it make sense to have a section to document them?
wendyreid: yes, probably.
Hadrien: documenting is important, so is classifying them, what affects screen readers, is it plateform specific, etc.
wendyreid: keep thinking about other programatic issues to document in the techniques. I'll rearrange that document too.
wendyreid: any other business or issue?
CircularKen: can we have a point about how incubation works ?
wendyreid: it's to have proof of need, use, etc. Any example of something, like a test implementation, a prototype. With reflection about feasability, including main stacks like accessibiliyty or security or privacy considerations.
Hadrien: I'm mostly done working on voice selection. I've started documenting what to extract, how to process text and tokenize it across different languages. I'll be happy to submit to the group working on TTS.
<Hadrien> General repo for this project: HadrienGardeur/
wendyreid: I'll update the PR and open another for the techniques. Next meeting in 2 weeks.
<Hadrien> On-going work for extracting structural elements: https://
<Hadrien> Examples on how structure could be extracted: https://