Meeting minutes
<dauwhe> Date: 2021-08-27
dauwhe: are there any new people?
Aimee: yes, hello!
Jen: Also new. I work with Aimee.
Aimee: we're focused on document a11y. A11y PDF specifically.
… here to contribute and learn!
Jen: I'm a braille reader. Read a lot of epub in my real life, in addition to having a professional interest!
George: Welcome!
Landmarks Nav
dauwhe: what is the purpose of landmark nav?
mgarrish: this is a continuing question. We created it originally to aid RS with hotkeys that go to specific parts of epub, stuff like that.
… but do RS even use these? And what are authors supposed to put in here?
… RS couldn't rely on there being specific content in here
… closest thing to standard is link to start of bodymatter
… we should provide some guidance, but if this isn't being used, then should we acknowledge that it isn't being used? Probably can't deprecate because some epubs already use it?
dlazin: does that disagree with the explanation at the last meeting, which said that we've had landmark since epub2?
mgarrish: i think dauwhe was getting at guides, which were kind of like a tour of the content. A little different.
dlazin: if this feature hasn't been adopted widely by this point, it sounds like the sort of thing that ought to be deprecated
duga: i think tours and guides were two different things, but I hesitate to say that its not being used. It's just being used for a specific thing: Finding the start of bodymatter.
… and its used for that purpose widely
… would be odd to deprecate it in that case
George: screenreaders have had keys that go to landmarks, which has been useful
… i've heard from students when there are landmarks in each chapter that provide an overview of said chapter
… so i don't think depreciation is appropriate, but i don't think we need to mandate that RS have specific navigation feature for them
dauwhe: are these things implemented in RS based on landmark?
george: as long as theres a landmark in the DOM than the screenreader can go to it
dauwhe: we might be using "landmark" to refer to two different things?
<Zakim> tzviya, you wanted to comment on guide v landmark
george: Referring to ARIA landmark here
tzviya: right, ARIA landmarks are a different thing. And this has lead to confusion over the years
… re. difference between guide and landmark. In epub2 guide was introduced. Guide is still widely used, and relatively short: toc, begin of content, index. Something like that.
… but some books are starting to use it to duplicate toc, which makes it less useful
… i would hesitate to deprecate entirely, but maybe offer guidance to make landmark more useful
<avneeshsingh> +1 for not deprecating landmark. we should provide some guidance.
mgarrish: in my issue i was trying to get at this, i.e. clarifying some things about landmark. And in addition maybe say that people are mainly using it to identify start of content
… this could head people off before they get confused
Hadrien: i think historically we have bad tendency to add more and more lists. For future versions of epub, we probably need less of these. Put some of this information in reading order, e.g. spine.
dauwhe: Identifying the point where people would start reading is valuable for the reader, but what is the best way to accomplish that?
dlazin: my interpretation is that deprecating something already used doesn't mean that the thing is going away immediately
… it means we're leaving this, and there is spotty implementation
<dauwhe> https://
dlazin: if you are new RS or author, it tells you this is not high on your list of features
gpellegrino: another use case that I know of is being able to jump to the in-book toc
… i.e. not the nav toc
mgarrish: if we give some guidance on what works, we have at least a basis for starting over. Maybe say at least put toc and start of content.
… and dlazin is correct about definition of deprecation from spec perspective, but we're also concerned about the practical implications of maybe causing books to get flagged in validation, etc.
avneeshsingh: coming back to main principles in charter, we have backwards compat clause
<MURATA> +1
avneeshsingh: i would say there is some worry about deciding to deprecate today. Safer to make more of these types of potentially breaking changes in future version of spec
duga: deprecation says this is not the recommended way of doing the thing you want to do. But this IS the way of pointing to the start of content etc.
… and it is the recommended way, in fact.
… and maybe we can return to this and set out a different way to do it in the future.
… but for now, I'm very much against deprecation
dauwhe: i'm with duga and avneeshsingh. I think we should follow original suggestion and clarify what this is for and what it does work for.
… not a new toc, or a completely different way of traversing the content
… maybe all that is needed for now is some editorial work
… does that seem reasonable?
duga: yes
<MURATA> Good to me.
<wendyreid> Proposed: Clarify the language for landmarks, close issue 1761
<dkaplan3> +1
<tzviya> +1
<dauwhe> +1
<toshiakikoike> +1
<duga> +1
<mgarrish> +1
<dlazin> +1
<avneeshsingh> +1
<gpellegrino> +1
<MasakazuKitahara> +1
+1
<MURATA> +1
<wendyreid> +1
<Bill_Kasdorf> +1
<BenSchroeter> +1
Resolution: Clarify the language for landmarks, close issue 1761
XHTML and SVG
dauwhe: apparently the SVG content doc section says RS should support searching of text, but the XHTML content doc section doesn't mention searching
… i see the point, but I'm also concerned that in general we try to avoid describing how RS should present epub to users
… my preference is to take out the line about SVG
mgarrish: I don't think we mandate certain UI features in any other point of spec. I agree on removing this. We leave this to the developers to figure out.
<tzviya> +1 to mgarrish
mgarrish: maybe just a note reminding RS people that SVGs can contain text
duga: fine with removing. Alternative would be to say that any text interactions that RS supports with XHTML should also be supported for SVG text. A more vague way of doing what we want.
wendyreid: gpellegrino which would you prefer, since it is your issue?
gpellegrino: no position as it doesn't strongly impact a11y. I just wanted to point out this discrepancy.
dauwhe: I have no objection to duga language. But probably more simple to just remove SVG bullet. Hoping that developers already know that SVG can contain text. Not sure that our reminder will change their minds about what UI feature to put in their RS.
<wendyreid> Proposed: Remove the search point from the SVG section, close issue 1774
<BenSchroeter> +1
<duga> +1
<tzviya> +1
<dkaplan3> +0
<gpellegrino> +1
<toshiakikoike> +1
+1
<wendyreid> +1
<dlazin> +1
<mgarrish> +!
<dauwhe> +1
<MasakazuKitahara> +1
<MURATA> +1
<Bill_Kasdorf> +1
Resolution: Remove the search point from the SVG section, close issue 1774
Navigation Document Processing
dauwhe: this is related to things we've discussed in the past. Our nav is HTML, so it can include ARIA attributes, lang, etc.
… gpellegrino proposes that we remind RS that they should honor these sorts of attributes when they present nav content in UI
… but some RS just strip everything except the text value of the stuff in nav
Hadrien: I'm worried about this. There are very good reason why RS do that.
… if we change this RS cannot use native UI elements to present nav
… would have to be a webview
… I don't think what is being suggested is achievable
mgarrish: I agree that we don't want to go here, but for a different reason. The nav was meant to make things simple for RS. Not sure its a good idea to expand complexity at this point.
gpellegrino: I understand the concerns. Can I amend the issue to just ask that RS adhere to lang attribute? Or to tell authors not to use those attributes in the nav, because they may not be used by RS. So author can find some way around this limitation.
<dauwhe> ack
dauwhe: i agree with Hadrien's concerns here. If RS wants to take info in nav and process it into native UI elements, we are not preventing them from doing anything. They can look for XML lang if they want.
… and then what they do with that is up to them
… to gpellegrino's point about advising authors, I don't think that's a good idea because we also have the idea of displaying the nav in the spine, and ensuring that it gets presented as HTML, and where all these attributes will be honored
Hadrien: i think it comes back to the fact that we're trying to serve two goals: 1) machine readable view, and 2) document view/webview
… but trying to do both in same document we're always going to have conflicts between those goals
… i don't think we can solve both needs with single document
… the only way to fix it is to basically have one thing that is meant to be processed, and another thing meant to be rendered the way it would be on the web
… this is how I'd deal with this eventually
<MURATA> Yes, I was writing an email about the use of ruby in nav docs to my colleagues in JDC.
mgarrish: i wonder if what is missing here is that there are requirements on how to create the text label. It's in the RS spec.
… maybe we could link to those?
dauwhe: yeah, that kind of makes sense
duga: in terms of lang, we're probably right by chance because people usually read books in the same language that their RS is set to. But we've never received a complaint about this.
… but it is a good point that was made by gpellegrino
dauwhe: we're not in a position to change the processing rules, even if using the same doc for processing and rendering removes duplication
… i would close this, but incorporate mgarrish suggestion to link back to RS spec
gpellegrino: may I add the issue to epub next so we don't lose track of it?
dauwhe: yes
mgarrish: maybe the point about lang is a statement we can make in the a11y section. Just to say that any UI should be accessible.
dauwhe: yes
<wendyreid> Proposed: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775
<gpellegrino> +1
<wendyreid> +1
<dkaplan3> "1
<mgarrish> +1
<dkaplan3> +1
<toshiakikoike> +1
<duga> +1
<dauwhe> +1
<tzviya> +1
+1
<Bill_Kasdorf> +1
<MasakazuKitahara> +1
<dlazin> +1
<MURATA> +1
<avneeshsingh> +1
<BenSchroeter> +1
Resolution: Add clarifying link to authoring specification, label issue as EPUB next and close issue 1775
<George> +1
Enabling zoom in FXL EPUBs
dauwhe: should we point out that zooming is important for a11y, even in the context of FXL epub?
gpellegrino: my idea is to add SHOULD statement. "FXL SHOULD enable zooming"
Hadrien: what makes it difficult is the fact that you can have spreads in FXL
… could be two iframes or two webviews. This makes it difficult to zoom in a good way because you have those two things side by side
… but not saying that we shouldn't do it
dauwhe: right, so what would happen if you try to zoom in on the boundary between two documents?
mgarrish: aren't we getting into UI requirements again? Not sure if this is always feasible.
… maybe this is something we could just point out. Or move this over to the FXL a11y doc rather that in the core spec.
dauwhe: do we know of existing RS that allow for zoom in FXL
gpellegrino: yes, all the mobile RS
mgarrish: but that's a feature of the mobile RS
duga: that's quite a bit of implementation on the mobile side, its not free
… but on the desktop side its a bit easier
… and yes, spreads add complication
wendyreid: almost the same comment as duga. Sometimes you see it implemented as a slider rather than pinch to zoom
… uncomfortable with adding this to spec because we don't talk about UI or UX affordances
… not sure we want to get into that territory
… but we can add this as a recommendation in the FXL a11y doc
avneeshsingh: i think this isn't something for the FXL content side of things. Maybe we can add statement on RS side encouraging the provision of zoom for FXL content. But not make this a normative statement.
dauwhe: getting the sense that a lot of RS already allow this. And historically we don't describe UX features in spec. I would note this in FXL a11y document rather than epub spec itself.
gpellegrino: my small concern is that the FXL note is more for authors than RS, so the suggestion may get ignored
dauwhe: are there implementations of FXL epub that don't allow zooming?
gpellegrino: yes, on desktop some don't allow this
dauwhe: are we okay with adding something non-normative to RS spec?
<dkaplan3> mgarrish++
mgarrish: can we add this to the a11y section? Just a suggestion to provide the option to allow user to zoom in
<avneeshsingh> +1 to genrral statement in a11y section of RS
gpellegrino: maybe link to FXL best practices document?
<dkaplan3> +1 as well, ditto mgarrish and avneesh
mgarrish: yes, once we get to FPWD we can link to it
<wendyreid> Proposed: Add a note to the accessibility section of the reading systems document, add mention in FXL accessibility note, close issue 1776
<gpellegrino> +1
<dauwhe> +1
+1
<wendyreid> +1
<mgarrish> +1
<dkaplan3> +1
<tzviya> +1
<toshiakikoike> +1
<MasakazuKitahara> +1
<BenSchroeter> +1
<dlazin> +1
<Bill_Kasdorf> +1
<duga> +1
Resolution: Add a note to the accessibility section of the reading systems document, add mention in FXL accessibility note, close issue 1776