W3C

– DRAFT –
FXL Accessibility Task Force Meeting

03 December 2024

Attendees

Present
CircularKen, gautierchomel, gpellegrino, Hadrien, wendyreid
Regrets
-
Chair
wendyreid
Scribe
CircularKen, wendyreid

Meeting minutes

<wendyreid> date: 2024-12-03

wendyreid: ken is scribe

<wendyreid> w3c/epub-specs#2669

<wendyreid> https://cdn.statically.io/gh/w3c/epub-specs/reformatting/epub33/fxl-a11y-tech/index.html

wendyreid: update to the document has been made with revised structure

content accessibility split into 2 sections - programmatic and visual

gautierchomel: the split I suggested was to be made to the main document but the stucture these should mirrored here

wendyreid: will do!

<gpellegrino> +1 to gautier

gautierchomel: techniques for reading system is a different audience, and has no place in this techniques document, should be separate doc

wendyreid: what else do we need to add?

gautierchomel: I think we should be more explicit on content on double page spreads and crossing pages

wendyreid: we have had feedback that reading order for EOUB and HTML is slightly different. Programmatically on the page vs the the reading in the EPUB spine

CircularKen: Tables, how should FXL represent tables, placing them in the page, having them described
… is it allowable to place tables in an iframe?

wendyreid: What is the use case for putting a table in an iframe?

CircularKen: Current software doesn't allow you to make tables
… it would be easier to export and place a table

hadrien: I would recommend to never use a table

CircularKen: Why?

hadrien: Reading systems use webviews, and multiple iframes, it gets complex

CircularKen: In our techniques doc, our recommendation is to use native HTML tables

hadrien: If a table isn't possible in HTML, using aria roles would fill in if needed
… preference is to use the HTML element, but can use ARIA if needed

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/table_role

JonasLillqvist: Is there a reason for the table issue in InDesign?

CircularKen: Pixel-perfect styling

JonasLillqvist: Is it not possible to do it with the styling?

CircularKen: I was looking at it as a workaround, for tables it would need to be accepted that it won't be pixel perfect

hadrien: If you use the right roles, it is possible

CircularKen: It might be easier to help them in InDesign, vs having to do it after

hadrien: Benefit of ARIA in this case, you can make it look however you want visually, but with the screen reader functionality

wendyreid: Can they insert tables in reflow? It's just a matter of styling

CircularKen: Yes, and it works well.

hadrien: I could also imagine a highly-stylized table, but it's still a table, some styling might escape the native element

wendyreid: Sounds like a gap in InDesign, gpellegrino have you mentioned this to them?

gpellegrino: We can make them aware of it, and some of these recommendations might work

JonasLillqvist: we have some remaining issues with reflowable tables too

gpellegrino: Just an overall comment, I don't think we should write these guidelines for InDesign
… these should be the best you can achieve with HTML and CSS
… the objective, but might not be feasible right now
… we want the authoring tools to produce this code
… we shouldn't let the limits of today's tools impact us

CircularKen: I know what you mean, I think I agree
… it does mean that someone looking at this document for best practices, it might mean they need to hand code their books

gpellegrino: There are other tools out there

CircularKen: I agree, show the best way to do it, but the how to actually do them, without a way, it loses its importance
… without the tools, we've run into this challenge with EPUB a lot
… techniques should maybe mention the best outcome, and the current limitations

gautierchomel: Full agree that we should be software agnostic

<CircularKen6> gautierchomel: I think the documentation shold be software agnostic

<CircularKen6> gpellegrino: I agree we need to keeo seperate the 3 sections prcincipes, techinqies, and the guide for auuthoring tools

<CircularKen6> wendyreid: yes we wnat to be hopefule and point authoring tools to the best practices

<CircularKen6> JonasLillqvist: there is still value in showing the limitations of current authoring tools

<CircularKen6> gautierchomel: agree there is value to have this elsewhere

<CircularKen6> wendyreid: agree that software is not to be mentioned in this techniques doc

<CircularKen6> wendyreid: we can genarlise and say 'current layout software' limitations

<CircularKen6> JonasLillqvist: footnotes and endnotes work differently can this be mentioned?

<CircularKen6> CircularKen6: how shoud we mention accessibility implementations of interactions?

<CircularKen6> wendyreid: if we build well then can add a11y

<CircularKen6> Hadrien: interactivity can break many reading systems

CircularKen6: Table of contents, if you have a long TOC that spans pages, it's going to be a challenge vs reflow

<CircularKen6> Hadrien: yes, a visual table of contents that spans multiple pages is not a navigation document

<CircularKen6> CircularKen6: worth an additional section in 2.3 navigation

<CircularKen6> Hadrien: in EPUB we are indebted to our resource based approach. Truy in RFL but much more in FXL as there are more resources

Minutes manually created (not a transcript), formatted by scribe.perl version 238 (Fri Oct 18 20:51:13 2024 UTC).

Diagnostics

Maybe present: CircularKen6, JonasLillqvist

All speakers: CircularKen, CircularKen6, gautierchomel, gpellegrino, hadrien, JonasLillqvist, wendyreid

Active on IRC: CircularKen, CircularKen6, gautierchomel, gpellegrino, Hadrien, JonasLillqvist, wendyreid, wendyreid6