Re: [A11Y] Question from the Locators TF

PS. Leonard, assuming that we parse documents where there are some semantic
present to classify content such as MathML, no layout is necessary for the
creation of locators.

On Mon, 18 Apr 2022, 19:08 Leonard Rosenthol, <lrosenth@adobe.com> wrote:

> Lars – I can see what working in a text-only work (e.g., simple books),
> but in a more significant work with images, equations, etc., you would have
> to (I would expect) download all that material and have it go through the
> layout engine to understand where it falls on a “virtual page”.  No?
>
>
>
> Leonard
>
>
>
> *From: *Lars Wallin <lars@colibrio.com>
> *Date: *Monday, April 18, 2022 at 12:59 PM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *Reid, Wendy <wendy.reid@rakuten.com>, public-epub-wg@w3.org <
> public-epub-wg@w3.org>, W3C Publishing Community Group <
> public-publishingcg@w3.org>
> *Subject: *Re: [A11Y] Question from the Locators TF
>
> Hi Leonard and all,
>
>
>
> Because of the nature of the OCF (and of the zip format) it is possible to
> stream down only the various document metadata and XHTML markup to use as
> basis for the creation of locators. We offer this at present as one method
> for creating locators with various resolution (characters, words, sentances
> and pages etc).
>
>
>
> These are then exposed as EPUBCFIs, and as they are deterministic they are
> cacheable and shareable across users and systems.
>
>
>
> This has worked well in all instances so far, regardless of device class
> and network since gzipped markup, with few exceptions, is very slim.
>
>
>
> Cheers,
>
> Lars
>
>
>
> On Mon, 18 Apr 2022, 15:13 Leonard Rosenthol, <lrosenth@adobe.com> wrote:
>
> One other consideration is that if the locators list is generated by the
> client, that means that the EPUB would need to transmitted **in its
> entirely** to the client before the locators could be produced.   That
> would seem to be a significant design limitation when considering random
> access to large content potentially on slower connections.
>
>
>
> Leonard
>
>
>
> *From: *Reid, Wendy <wendy.reid@rakuten.com>
> *Date: *Thursday, April 14, 2022 at 5:18 PM
> *To: *public-epub-wg@w3.org <public-epub-wg@w3.org>, W3C Publishing
> Community Group <public-publishingcg@w3.org>
> *Subject: *[A11Y] Question from the Locators TF
>
> Hi all,
>
>
>
> The Locators TF is working on an interoperable method for generating page
> locators across reading systems and books. Just to give an idea of what
> we’re considering, we have developed a skeleton for an algorithm that could
> parse an EPUB file and generate “locators” at defined intervals.
>
>
>
> One of the questions we are tackling now is where the locators live after
> generation. In practice, reading systems do not typically write to the EPUB
> file, meaning that if the locators are generated upon loading, they would
> potentially live in a “virtual” space accessible to the reading system.
> This virtual locator list would be usable by the reading system for things
> like search or navigate to page but would not appear in text or in the DOM.
>
>
>
> This is the question we need help with. Our understanding is that locators
> need to be accessible to assistive technology, though the user may turn
> them on or off, which means we need to explore how locators need to be
> changed to accommodate this. Any advice you can provide on:
>
>    - the use cases of page numbers with AT,
>    - what use cases need to be supported,
>    - are there other ways page numbers/locators need to be exposed to the
>    user or AT
>
>
>
> Please let us know if there are any questions, or if this is best
> discussed on an upcoming call, our next one is April 29th at 10AM ET.
>
>
>
> Thanks,
>
> Wendy
>
> Co-chair, EPUB3 WG
>
>