Meeting minutes
Fixed layout
matatk: where there might be challenges for accessibility.
… 1. support for reading order.
… 2. authoring tool support offering that / User agents.
… 3. title of doument
wendyreid: introduction: fixed layout origin - started as a joint community group in cooropteration with EAA / A11y 1.1 spe.
… concern around FL (Fixed Layout)
… miss information fixed layout was exempt misconseption.
… best practices document would be good for stating what you could do with fixed layout for a11y.
… currently not fully accessible. Publshers can do some work to make it as accessible as possible.
… explain where a11y can be implemented. feedback on language and where to improve.
… we know this does not cover everything, we want to do a techniques document with code examples.
… FL a11y - potential ideas to solve some of these issues. this Note is not done. there is more work to do.
matatk: plans for the future is great and code examples would be super helpful.
George: the recommendation for EPUB is a reflow type document which is the most accessible format.
… fixed layout is a problem the WG agreed to publish this as a draft. this is not finalized.
matatk: it does seem more final than that when reading it. but great to know this isn't the case
wendyreid: small error on our part when we published we forgot to put that in the spec when we published. this is a draft and will be changed.
janina1: knowing there will be problems with FL support for user agents to try to reflow. There are some cavets, a techniques document will be very help. concerned with the title if it stops with accessibility that it will achieve this. In TR space this is a concern. suggestion add a : an phrase to retitle this. setting expectations.
<George> +1
matatk: : Yes we will get to that specific issue.
gautierchomel:
gautierchomel: Limits of FL, it is not reflowable. aside from that there were different experiments. FL were made where Reading Order (RO) you may not even know you are reading a fixed layout.
… remaining problem RO path of a FL. Hachette in France RF inside of FL content with Java Script button to switch. but realized Screen Reader could access the content of the FL, and announce to the user we thing that the future this reflow can do when using NVDA you can have braille audio to get the text
… main learning while writing this document the limits of FL could be addressed in the near future. the authoring tools is a concern at the moment.
The spec's support for reading order info
matatk: is there support for RO information. sounds like yes
<wendyreid> https://
Hadrien: spex allows the inclusion of that but it is not well document for FL documents.
… since no one considers FL books as accessible so they are not including it.
… problem with FL absolute positioning. content is chopped up word by word, letter by letter. which is not helpful, and could not be in the right reading order.
… also problematic FL also has a concept of Spread of two resources side by side on two pages. the Reading order is across the spread. from Resource A (left) to Resource B (right) which is a major issue.
… number of FL where there are not text but inside the image.
matatk: some cases where the current spec does provide the RO could be useful but some examples where there is no text or text in various resources when in side by side spreads.
janina1: audience are we thinking paper, vs iphone screens etc
wendyreid: I agree happy to go in and bump up the language in that section. providing additional clarity of RO is perceived which comes from the DOM and spine.
… more clear where RO comes form and how to improve it.
… we do make mention of FL content generally consumers readers readers reading on a variety of devices, from a cell phone to a huge monitor.
… if you are relying on a two page spread on a mobile phone would be next to impossible on these small screens;
… publishers are taking the print version and converting to digital.
Hadrien: FL invented for the IPAD. published in print where the visual design provides information.
Authoring tool support
Hadrien: FL is used for Manga and comics.
<George> I have never seen a fixed layout textbook in EPUB.
matatk: aside from the RO issuesfor authoring tools do they support this concept of RO?
wendyreid: authoring tools is tricky depends on who the publisher is. Big publishers have their own proprietary and closed but we can see the output.
… most common is Adobe Indesign. they are making strides to make it more accessible. Circular Flo do this for Fixed layout and is very good.
… most smaller publishers are not making FL books.
… there are tool changes out there but are diverse.
Hadrien: publishers for manga and comics but usually dont produce accessible content at all, just images.
matatk: we are asking these questions to drive topic 3 on the title.
Title of the document
matatk: historically documents like this: for titles generally if we find that it is totally possible to make it accessible we would go one route vs. if something isn't possible / gaps we use words like considerations, gaps, etc.
… sounds like some areas we could support a11y but other areas where it is a lot more challenging.
wendyreid: we took the optimistic approach trying to make FL as accessible as possible.
… maybe adding "Best Practices" but happy to hear other options.
matatk: we want to avoid someone thinking if they follow the best practices that they are done and fully accessible.
… if there ae limits as long as those are in the document will help.
… even following the best practices is not enough.
janina1: techniques and limitations (best practices) could work.
AvneeshSingh: title fixed layout best practices and limitations looks good. how can we meet a11y spec 1.1
… impression we are trying to meet 1.1 it would be nice to restruture in a way here is the a11y challenges and possible solutions. and those where no solution is clear.
George: +1 to name change on the document
… would like to see workarounds or techniques, and opportunities
… we need a robust solution that meets WCAG Profile AA for comics, manga, children's books
… I see a way forward, but it will require significant work
Future plans
Interlinear
janina1: Interlinear is about multi-language support
… there are many situations where multiple lines of content, in multiple languages, need synchronization
… not on the word by word level, as languages do not inter-relate in that way
… but certainly phrase by phrase, and line by line
… such inter-linear formats are not well supported today neither by ePub nor HTML
… I personally rely on TTS to consume such content and it is very challenging to hear a cacaphony of voices and go back and forth
… also note, full screen braille displays are now on the market
… which can support multiple lines of content
matatk: One example is learning a language or reading a well known text in a native language
… in a structural sense, you may have two related tracts of information that require synchronization
AvneeshSingh: We spoke last TPAC on this topic. I support investigating, can these be done in the native specifications?
… what support do we need from the ePub community?
janina1: We are happy to investigate implementation in HTML as well
matatk: We in APA are happy to pursue this in other WGs as well
Lionel_Wolberger: I think interlinear is often needed for canonical texts - prayer books; cultures' holy texts; wide interest.
<Zakim> tzviya, you wanted to ask what the specific request is
tzviya8: +1 to the importance. Not clear what is missing. Lack of support on ePub reading devices?
Lionel_Wolberger: Tzviya is correct that visual coordination of inter-linear content is well understood
… and sighted people consume the content as coordinated
… APA's interest is that this coordination is not expressed on a semantic level
… there is no indication for the AT to coordinate the two lines
<George> I have a meeting I must go to.
tzviya8: I want to warn against over thinking this
… even visually, the association is often merely consecutive
wendyreid: Regarding crossing the boundary of the spread, what is known as 'over the fold'
… the next phase of ePub work will have a fragment-based focus rather than resource-based
… currently we have some cases of fragment-based functionality (via Smile for example)
… Note, we do not tell publishers how to author their content.
… we edge into this case regarding accessibility
… inter-linear coordination as discussed here seems doable with HTML + CSS
CharlesL1: Current UX/UI conventions regarding text messaging seems to be a similar coordination challenge as is being raised here
… I suggest we look to that for ideas and/or inspiration
Annotations & Locators
wendyreid: (1) Annotations.
… (2) Locators.
… (3) Fixed layout, and how to make fixed layout reflow
matatk: We understand ARIA is looking into annotations
matatk: Other considerations, how rich are the annotations? As Wendy indicated, annotations can be quite complex
AvneeshSingh: AT coordination is difficult because determining reading position is itself very difficult
<wendyreid> +1 Avneesh
<wendyreid> Lionel_Wolberger: I use an epub reader on my iphone, I find footnotes work well
<wendyreid> AvneeshSingh: The issue is more with the virtual buffer with screen readers
janina: There are challenges with cross-platforms, different technologies
… different contexts
… on an airplane versus giving a lecture
Lionel_Wolberger: I found in one client, footnotes are well-implemented with footnotes
wendyreid: Differentiating footnoates and annotations
… Footnotes, in old ePub and new frameworks, we have reasonable support for footnotes
… publishers do not consistently use those frameworks
… but footnotes are so well established, with durable conventions for where they are located
… annotations are separate from the text in a wholly different way
matatk: Some factors that bear consideration, virtual cursor position, focus order, landmarks
… the latter (landmarks) are surprisingly well supported by screen readers (though not much outside the realm of SRs)
duga: Annotations is not currently in scope of ePub
… ePub is agnostic to annotations. I want to emphasize, annotations are an added on feature that, currently, ePub has nothing to say about them
… with the exception of (perhaps) export
matatk: Is there consensus that ePub will be addressing annotations in future (its semantics)?
duga: IMHO we intend to explore export only
wendyreid: Yesterday 23 Sept we had an initial exploratory conversation re: annotations (after not addressing them for a while)
… We see wide variation in the reading systems and the affordances provided by the reading systems
… perhaps we need to spell out further the desired experience(s): here are the features, here is how we would like it to work
… many reading systems are working on accessibility, and position is a real challenge
"Expert handlers"
wendyreid: we are in a contradictory position where (a) knowing the screen reader cursor would be extremely helpful but (b) to preserve the privacy of the end-user we do not want to know screen reader position
janina1: Expert handlers are experienced, e.g. in a collaborative document
matatk: Expert handlers might be implemented on the user's side by all kinds of tools
wendyreid: Checking for understanding: Is the PDF renderer in the browser an example?
matatk: MathML, MusicML are rendered in the browser
… some people want extra program, software or apps to provide a more detailed and interactive rendering of the content
… 'expert handler' is our term for this type of interaction
janina1: We suspect that ePubs particularly in the educational context will have significant use cases based on these handlers
AvneeshSingh: yesterday ePub discussed an educational use case in depth
… we tentatively concluded that the educational context needs its own approaches here, as they are generally in a Learning Management System
Lionel_Wolberger: If ePub has its spec at source, and can't be responsible downstream, why does APA think ePub should be supporting this?
janina1: ePub content will host specialized formats that will never be rendered well by deafult
… mechanisms to handoff back and forth will be helpful
… in music textbooks there will be examples in the text
Lionel_Wolberger: The word 'embedded' helped me in Janina's response
… ePub may have a method to mark <start> and <end> of an embedded section that may benefit from an expert handler
wendyreid: Thank you, APA!
<Lionel_Wolberger> +1
Hadrien: on the Web, I wouldn't be surprised if education platforms end up with specialized viewers/handles as Web apps rather than external expert handlers
… for example, IIIF viewers feel like one of these expert handlers
Accessibility Maturity Model TF & Equity CG
<jkline> just fyi...IRC drops me frequently
Is the APA AMM ready for publication? Why?
Fazio: We have worked on this for 4 years and socialized it widely. over 200 issues have been handled in github.
<jkline> Jennifer, hi! Glad you find the book useful!!
<Sheri_B-H> I would add to Lionel's minutes that we've tested it with several large organizations (without naming names)
Sheri_B-H: And the MM has been tested by serveral large organizations
janina1: APA Chairs advocate for moving forward with this document
… one of the organizations that tested it, is attending this meeting
CharlesL: At Vancouver TPAC Bennetech learned about the maturity model
… decided to both join the MM Task Force and implement this model
… this was accepted as an official corporate OKR
… Bennetech is also exploring a consulting service to leverage this model to assist other organizations
janina1: Bennetech's statement illustrates how this MM fills a niche
… it provides a method to both take a 'snapshot' of accessibility status and enable tracking progress over time
<Sheri_B-H> (david covered my comment)
Fazio: Note, there are other maturity models in the aaccessibility space.
… a natural outgrowth of using a MM is an opportunity to sell and provision tools needed to meet needs and/or gaps revealed in the process of engaging with the MM
… a major differentiation is that the W3C's MM has no such 'upside' from MM-related selling of services
Is the APA AMM NOT ready for publication? Why?
janina1: It's been a while since we had a thorough and wide review from the public
… I concur that we have had engagement with the MM. These tend to be detailed oriented, by insiders with concern with "the weeds"
… I feel there is another kind of socialization and wide review that I feel, from experience, we need prior to recommending this for publication
Sheri_B-H: We foresaw in MM the need for both (a) a document and (b) an associated HTML tool to facilitate its use
… such a tool would be another differentiator from all the other MM's out there
… this tool would not host the data
CharlesL: Since last MM updated working draft, we did not see many github issues,
… but I found glaring errors in the spreadsheet (not calculating things correctly, for example)
… this made me concerned that people have not tried the tool.
Fazio: I advocate going one step at a time. First, publish the document. Then finetune the tool
… the latter tool also requires tackling the scoring issues that have arisen
<Zakim> chaals, you wanted to suggest building and maintaining serious reporting tools isn't a good thing to do in a W3C WG, but publishing something you have a way to maintain is a good thing to do.
chaals: +1 to David. If there are currently no more comments, go ahead and publish
… you intend to maintain it, and will receive more feedback prior to publication
… IMHO a Working Group is not a great place to develop a tool
<Sheri_B-H> Just to make it clear - I don't think the lack of a tool is a sufficient reason to hold it up. But some might
chaals: there is an advantage to a non-WG entity, such as a third party, making the tool
… a WG making the tool has built-in inefficiencies, as the WG has a world view that may end up getting baked into the tool
… don't try too hard for the WG to make the definitive tool
Fazio: We were thinking of making a template
chaals: Even a template can benefit if created by a grup, separate from the WG
Latest Editor's Draft: https://
Are our approaches sufficiently coordinated? How do we do better?
JenStrickland2: Equity CG was started to help define Equity at W3C
… We looked at Equity, Sustainable Web, in the context of other factors like Privacy
… the topic of having a Maturity Model arose as we worked on this
… We prioritize an approach that does NOT change the Accessibility Maturity Model
… and enforced this approach, as this led us to take some suggested changes to the MM
matatk: Recap: Equity started building on this work, filed some tickets for AMM (accessibility maturity model)
… then found we at Equity were using an out-of-date version of the AMM
Lionel_Wolberger: Discussion continues on the EMM (Equity Maturity Model), AMM (Accessibility Maturity Model) and their relationship(s)
JenStrickland2: EMM, when it cites AMM, points to AMM and does not seek to alter it
… EMM also curates pointers to other external groups such as Privacy
FazioL: AMM supports EMM's work
… AMM began as a CG, where it was honed and narrowed down
<Fazio> this is why we made it extensible
JenStrickland2: Brings a metaphor of a pie, composed of different slices of different pies: a slice of cherry pie, a slice of peach pie, and so on
<Fazio> and Fazio likes it
<Fazio> the mixed pie
JenStrickland2: this 'pie' is composed of internationalization, sustainable web, accessibility, privacy
Sheri_B-H: Expands on the history and adds some details
… MM began as a CG in AGWG
… then moved over to APA
<matatk> +1 to Sheri_B-H re keeping it accessible (after getting it accessible)
Sheri_B-H: making a distinction between WCAG, about 'getting something accessible' and MM, 'keeping it accessible'
Is the Equity CGs document a snapshot of APA AMM? At what point? How maintaining synchronization?
matatk: Is the EquityCG's document a snapshot of what we produce, if so, from when is it taken, and how do you keep it synchornised?
JenStrickland2: We copied the content as of August 5 2024 into a Googledoc.
matatk: I am still trying to understand where to get a slice of pie, and
… you are building on the work the other groups are doing, not changing that downstream, so what is the need to start with a snapshot?
JenStrickland2: As a proof of concept to work on something. We're not worried about having to synchronise - we can deal with updates, and we are only building a draft idea at this stage.
… We need something more solid to work with at some point, so starting with the structure of the AMM and then adding some things like a statement of principles is a way for us to work on what we are trying to achieve.
CharlesL: The most recent published draft was 18 June, did you take Editors' draft on August, or take the latest published version from TR (which is actually the content we had as of June)
JenStrickland2: The /TR Working Draft, content is dated June 18
<Roy> https://
Sheri_B-H: If we put together a list of proposed changes before we republish, then we can hand those off to other groups.
chaals: [Producing a clear list of changes from draft to draft is IMHO something that everyone should ALWAYS do ...]
<matatk> +1 to chaals re changes lists; always helpful!
Fazio: Thank you for the explanation - I think you've explained to us what we needed to understand so we can meet your expectations and needs from us.
… This is like copy-editing - you can take our structure and see how well that works for what you are doing, and I think that's a pretty good way to appoarch the development. We can look forward to a future where it's easy to collaborate and see where we both go when we are both further along our development processes.
JenStrickland2: Are people familiar with "RACI (Responsible, Accountable, Consulted, Informed)? Could be useful for the AMM as parent to have a RACI chart, so you know who is waiting to hear about changes proposed, people you might consult before you agree a change, ... Equity CG would want to be informed about changes
Fazio: We have github repo that lets you do that.
Lionel_Wolberger: W3C standards have always depended on each other. This is something we know how to do around here. Not sure there is a special case here.
JenStrickland2: We are trying to do that
Sheri_B-H: We are experiencing some growing pains, as we are learning the ropes in practice.
<Fazio> +1 to growing pains
Lionel_Wolberger: There are differences between technical standards for making something, and processes for maintaining a status in an organisation...
… Equity wants to know when AMM changes, are there parallels in other groups that we see working on that pattern?
CharlesL: I don't think we have a change log...
janina1: we have github
<Roy> History of publication: https://
CharlesL: Not a human-friendly one that people can easily read. I think we should have a human-readable changelog (not just github record of all commits)
… think we should also have an appendix of people relying on / using the specification.
<matatk> +1 again to the idea of nice change logs :-)
<Sheri_B-H> human-friendly changelog is with a review with Equity and other teams that are relying on it was what I was proposing
<matatk> +1 Sheri_B-H
janina: There are people who are happy in github, and people who aren't, in our community. I suggest the same exists in relation to Google Docs. We haven't worked out how to coordinate those two worlds. And not just for this specific example case.
<Sheri_B-H> it== the accessibility maturity model
janina: There are things we can do that help like writing commit messages that actually explain what is changed, instead of just "update to doc".
… Not sure how to characterise doing this from Google Docs.
… Github records who said what and where changes came from.
… we should be able to rely on tooling to help, but it takes some effort on top to make it work well.
chaals: tooling is always a compromise. There are differences and tradeoffs that have to be made, but that is a constant in the life of a group.
<Zakim> chaals, you wanted to react to janina to say tools, ....
matatk: I don't want to impose stuff about commit messages on the group but there are simple things we could do.
… I wanted to mention the RACI chart. I read this as "please coordinate" and I think we should make our processes for doing that fulfil what Jen was asking for. There are 3 pathways...
… 1. Friendly changelogs
… 2. Have a human liaison, which we do.
… 3. A horizontal review process.
… These give us several ways to make sure the communication that happens, and I hope it is working. We can also talk more if something isn't working, ubt I am optimistic that we can manage this successfully given our current approach.
JenStrickland: regarding Equity CG's model, we are trying to sketch a proof of concept at this stage. Would be good to get the CG working from a similar perspective. We're small, new, and we don't manage to be in all the meetings together, so i might just make a rough sketch as a prototype to see if that helps us. We don't yet need to produce a
full-blown deliverable.
charrrlesL: You're working in google docs. Are you planning to write something that we can point to like a CG report?
JenStrickland: We would like to do that.
<Roy> CG report requires
JenStrickland: when we get to the point where we are ready to publish stuff.
<Sheri_B-H> slight technical correction - you can point to a google doc (or sheet) from the document in GitHub, but it has to be a w3C google doc/sheet, it can't be owned by someone else
Has Equity (others) discovered an incompatibility to the APA AMM that requires resolution?
JenStrickland: Not really yet, beyond an editorial issue that got resolved.
matatk: We see no known showstoppers, then...?
matatk: Thank you for this session, I think it has been helpful and we understand each other better, which is good news. Next steps, APA looks at changelogs, between APA and Equity CG we have a liaison, and it seems to be working, and we understand that they snapshot you are working on is fine for your current purposes, and we know how to talk to
each other any time there is something we need to talk about.
[BREAK]