- From: Aaron Leventhal <aleventhal@google.com>
- Date: Thu, 22 Aug 2019 11:00:18 -0400
- To: George Kerscher <kerscher@montana.com>
- Cc: Avneesh Singh <avneesh.sg@gmail.com>, "White, Jason J" <jjwhite@ets.org>, Leonard Rosenthol <lrosenth@adobe.com>, public-publ-wg@w3.org, Joanmarie Diggs <jdiggs@igalia.com>
- Message-ID: <CA+1LECTcADg1Fh=00FJm2Q9jxx3DNF7LTRHtsr2UvMomR9Eg-g@mail.gmail.com>
George, sounds like you are saying that if Docs is to export to EPUB (I don't think it currently does, but maybe there's an extension?) -- then there would be a set of requirements to ensure good quality navigation. Aaron On Thu, Aug 22, 2019 at 10:48 AM George Kerscher <kerscher@montana.com> wrote: > Hello, > > OK, when using Google Docs and using the publish this document, the spot > of the page break at the top must contain the doc-page-break attribute. > Also, when generating the EPUB version, this is the spot > > That must be linked Along with the number that must be in the page list in > the navdoc. > > In this way, people using the print version and the EPUB version can be on > the same page, grin. > > > > Best > > George > > > > *From:* Aaron Leventhal <aleventhal@google.com> > *Sent:* Thursday, August 22, 2019 7:08 AM > *To:* Avneesh Singh <avneesh.sg@gmail.com> > *Cc:* White, Jason J <jjwhite@ets.org>; George Kerscher < > kerscher@montana.com>; Leonard Rosenthol <lrosenth@adobe.com>; > public-publ-wg@w3.org; Joanmarie Diggs <jdiggs@igalia.com> > *Subject:* Re: Running headers/footers / new version of DPUB-ARIA? > > > > Avneesh, Google Docs has a "publish this document" feature, as well as a > mode where users can read, but not edit a document. In the published case, > there is no caret navigation built in. Being able to skip over running page > content should work in any of these modes. > > > > When zooming in the browser, I would not currently expect pagination to > change at all. However, if such a zoom and reflow feature did exist, and > repagination did occur, I imagine that the user would want to be able to > refer to original page numbers, similarly to Braille print page indicators. > I'm not sure how this would be handled, but I suppose it's worth discussing > how the role doc-pagenum would be used. Let's think it out. Personally I > don't think it should be required for the doc-pagenum role to be inside of > a doc-pageheader or doc-pagefooter, but that it could optionally be. I > don't see it as an issue to have the browser/AT combo work with either > scenario. > > > > Aaron > > > > On Thu, Aug 22, 2019 at 7:53 AM Avneesh Singh <avneesh.sg@gmail.com> > wrote: > > Clarifying it further. My example is from publishing perspective i.e. > mostly read only documents that are published. > > If we are looking at this from purely word processor perspective, then I > wonder if this is a publishing related issue? > > > > With regards > > Avneesh > > *Sent:* Thursday, August 22, 2019 17:19 > > *To:* White, Jason J ; George Kerscher ; 'Aaron Leventhal' > > *Cc:* 'Leonard Rosenthol' ; public-publ-wg@w3.org ; 'Joanmarie Diggs' > > *Subject:* Re: Running headers/footers / new version of DPUB-ARIA? > > > > > > I think that I am able to get the expected functionality, at the same time > I am still confused with placing page numbers in footers or headers. > > Explaining it in step wise manner > > - The text will reflow but the headers and footers are expected to remain > constant. > > - For example, if the document has footers after approximately 20 lines > and the user zooms to double size, then there will be one footer after each > 7 or 8 lines. > > - This means that page breaks will also flow down. > > > > Now, how can one mark persistent page number inside header or footer. In > such a case the page number in footer will become reading system > responsibility which will change dynamically instead of being > responsibility of content. > > > > If we want to have static page numbers in header or footers then it should > be a fixed layout, > > or the header / footer should also reflow when user zooms the document. > > > > With regards > > Avneesh > > *From:* White, Jason J > > *Sent:* Thursday, August 22, 2019 1:35 > > *To:* George Kerscher ; 'Aaron Leventhal' ; 'Avneesh Singh' > > *Cc:* 'Leonard Rosenthol' ; public-publ-wg@w3.org ; 'Joanmarie Diggs' > > *Subject:* RE: Running headers/footers / new version of DPUB-ARIA? > > > > Perhaps the screen readers should offer a means of querying the > header/footer information. However, that’s outside the scope of ARIA and a > matter for each implementation. This would be especially useful in a word > processor, as the user needs to be able to read and edit it. Another option > would be a simple “go to header/footer” navigation command in the > application itself. > > > > I’m not sure that I fully understand George’s question about export to > EPUB. When the text is reflowed, the pagination may change, but the > header/footer text often wouldn’t. A good example would be printing to > different page sizes or font sizes. If the text still fits, then presumably > it should simply be printed wherever the new page breaks lie after styles > are applied to the document. It’s very much the same as what happens if you > make changes to a document in a word processor. If there are no explicit > page breaks in the markup, then the page header/footer should be able to be > applied to an entire div/section of the document: > > > > <section role=”doc-chapter”> > > <!—Applies to all pages in this section --> > > <div role=”doc-pageheader”>[…]</div> > > […] > > </section> > > > > I’m not in a position to answer Aaron’s earlier question about the > schedule for specifying new ARIA features for these use cases. I think > that’s a question for the Chairs, or for a group meeting. > > > > *From:* George Kerscher <kerscher@montana.com> > *Sent:* Wednesday, August 21, 2019 12:50 PM > *To:* 'Aaron Leventhal' <aleventhal@google.com>; 'Avneesh Singh' < > avneesh.sg@gmail.com> > *Cc:* 'Leonard Rosenthol' <lrosenth@adobe.com>; White, Jason J < > jjwhite@ets.org>; public-publ-wg@w3.org; 'Joanmarie Diggs' < > jdiggs@igalia.com> > *Subject:* RE: Running headers/footers / new version of DPUB-ARIA? > > > > Hi, > > > > A few items here: > > > > I totally agree that while creating content as in GoogleDocs, it is > perfectly fine to have running footers and Headers. Even better if I, using > my screen reader, do not need to encounter them. > > > > The export to EPUB would not put this in the reflowed content, right? > > > > Page numbers are one of those things we have called “skippable” > structures. In an audio book, you may want to go to page 34 and hear that > this is page 34, but in continuous reading, you want to skip (filter is > your term) over it. However, It is always good to stop and find out where > you are. > > > > Seems that this agreement. > > > > Best > > George > > > > *From:* Aaron Leventhal <aleventhal@google.com> > *Sent:* Wednesday, August 21, 2019 8:46 AM > *To:* Avneesh Singh <avneesh.sg@gmail.com> > *Cc:* Leonard Rosenthol <lrosenth@adobe.com>; White, Jason J < > jjwhite@ets.org>; George Kerscher <kerscher@montana.com>; > public-publ-wg@w3.org; Joanmarie Diggs <jdiggs@igalia.com> > *Subject:* Re: Running headers/footers / new version of DPUB-ARIA? > > > > George -- we're in agreement. This will help paginated content just seem > like one continuous document when you're reading. Basically, we're trying > to make it so that you don't see this stuff when you're word processing > unless you want to. By having the word processor (like Google Docs) mark > these up, the AT can decide to filter those things out, which they can't do > right now. See Glen Gordon's comments in the bug. This will allow them to > have similar functionality for this in Google Docs as they do on MS word. > Where are we not aligned here? > > > > Avneesh -- DPUB is very close to being able to help us have an awesome > experience in Google Docs. Makes sense as a use case, right? > > > > Jason -- can you give an example? I think we want 2 things from the page > number -- to be able to report it when the user wants it, and to be able to > filter it out when the user just wants to read continuously (similar to > filtering out the page header). > > > > On Wed, Aug 21, 2019 at 10:38 AM Avneesh Singh <avneesh.sg@gmail.com> > wrote: > > I think that the confusion comes from the design. Most of the DPUB aria > roles are from the perspective of a refloable document like HTML and EPUB > 3. On the other hand the discussion in this thread looks more oriented > towards somewhat like a fixed layout document. > > > > With regards > > Avneesh > > *From:* Aaron Leventhal > > *Sent:* Wednesday, August 21, 2019 19:56 > > *To:* Avneesh Singh > > *Cc:* Leonard Rosenthol ; White, Jason J ; George Kerscher ; > public-publ-wg@w3.org ; Joanmarie Diggs > > *Subject:* Re: Running headers/footers / new version of DPUB-ARIA? > > > > Thanks, I didn't realize that's where the page number would currently go. > I'm not sure it's ideal. > > <span id="pg04" role="doc-pagebreak" title="4"/> > > A page break line would likely show up as a horizontal line. Under the > horizontal line is a header, then adjacent to that comes the page number. > How would that be done in markup? > > We don't want 2 page breaks, and the page break and page number aren't in > the same place. > > <hr role="doc-pagebreak"> > > <div role="doc-pageheader"> > > My header <span role="doc-pagenumber">4</span> > > </div> > > > > Additionally, in the page break example, the page number usage is in the > title attribute, which would not be visible text. Although it's not > explained, t's not clear to me from the example or spec text that > browsers/ATs could expect a page number inside a child text node. > > > > IMO we should have a separate role for page numbers, or put them inside > the header or footer objects, but putting them as part of the page break to > me will cause a problem with the above example. > > Aaron > > > > On Wed, Aug 21, 2019 at 10:17 AM Avneesh Singh <avneesh.sg@gmail.com> > wrote: > > doc-pagebreak already exists in DPUB aria roles for locating the page > marks. They can have a visible page number as well as invisible page number. > > > > > > With regards > > Avneesh > > *From:* Aaron Leventhal > > *Sent:* Wednesday, August 21, 2019 19:12 > > *To:* Leonard Rosenthol > > *Cc:* White, Jason J ; George Kerscher ; public-publ-wg@w3.org ; > Joanmarie Diggs > > *Subject:* Re: Running headers/footers / new version of DPUB-ARIA? > > > > Thanks Leonard, don't we want to be able to differentiate the headers from > the running headers? It's the repeated running headers that users want to > skip over. > > The headers that are part of the content seem different, like a <header> > in HTML. > > > > On Wed, Aug 21, 2019 at 9:35 AM Leonard Rosenthol <lrosenth@adobe.com> > wrote: > > In PDF, we treat page numbers as a separate thing from the header/trailer > (and yes, you can have the former inside the latter). We also have a > “class” for bates numbers and a few other vertical-specific elements. We > have found that it is important to be able to unique identify them. > > > > Headers and Footers aren’t necessary tied to pages – you could have a > section with a header or footer as well, so perhaps just `doc-header` and > `doc-footer` (and `doc-pagenum`). > > > > Leonard > > > > *From: *Aaron Leventhal <aleventhal@google.com> > *Date: *Wednesday, August 21, 2019 at 8:55 AM > *To: *"White, Jason J" <jjwhite@ets.org> > *Cc: *Leonard Rosenthol <lrosenth@adobe.com>, "kerscher@montana.com" < > kerscher@montana.com>, "public-publ-wg@w3.org" <public-publ-wg@w3.org>, > Joanmarie Diggs <jdiggs@igalia.com> > *Subject: *Re: Running headers/footers / new version of DPUB-ARIA? > > > > Sounds good. > > - How about doc-pageheader and doc-pagefooter? > > - Possible definition: repeated section of text that appears at the > top/bottom of pages in a document, potentially containing a title, page > number or other information > > - Should the page number get its own role, e.g. doc-pagenum? Should it > exist within the doc-pageheader/doc-page-footer? > > - Should the new roles inherit from contentinfo? > > > > On Wed, Aug 21, 2019 at 8:05 AM White, Jason J <jjwhite@ets.org> wrote: > > If there’s already a mapping to accessibility APIs via PDF readers, then > we could use it here too. > > > > Screen readers could offer a command to query this information, if > desired, just as there is for window titles. > > > > *From: *Leonard Rosenthol <lrosenth@adobe.com> > *Date: *Tuesday, August 20, 2019 at 21:45 > *To: *George Kerscher <kerscher@montana.com>, 'Aaron Leventhal' < > aleventhal@google.com>, "public-publ-wg@w3.org" <public-publ-wg@w3.org> > *Cc: *'Joanmarie Diggs' <jdiggs@igalia.com> > *Subject: *Re: Running headers/footers / new version of DPUB-ARIA? > *Resent-From: *<public-publ-wg@w3.org> > *Resent-Date: *Tuesday, August 20, 2019 at 21:45 > > > > FWIW: Headers & Footers can be properly identified in PDFs and exposed > accordingly to AT (so that they aren’t read multiple times). In fact, > PDF/UA (the PDF standard for Universal Accessibility) calls out their usage. > > > > Leonard > > > > *From: *"kerscher@montana.com" <kerscher@montana.com> > *Date: *Tuesday, August 20, 2019 at 4:35 PM > *To: *'Aaron Leventhal' <aleventhal@google.com>, "public-publ-wg@w3.org" < > public-publ-wg@w3.org> > *Cc: *'Joanmarie Diggs' <jdiggs@igalia.com> > *Subject: *RE: Running headers/footers / new version of DPUB-ARIA? > *Resent-From: *<public-publ-wg@w3.org> > *Resent-Date: *Tuesday, August 20, 2019 at 4:35 PM > > > > Hello, > > > > This is just my opinion. Running headers and footers are very intrusive > while reading. I encounter these many times in PDF documents. The same > information is constantly repeated. Fortunately, I do not encounter this > while reading EPUB. I can understand that it might be useful for the > Reading System to provide “where am I?” information as one is reading, but > including this over-and-over again in the content would be horrible. > > I am reading using Assistive Technology (AT) and the TTS reads to me. I > imagine this would also be painful if a person was using the read aloud > function in Reading Systems. > > > > I could see the same problem in an audio book. Nobody would want to hear > those running heads and footers in the audio book. > > > > My $.02 > > > > Best > > George > > > > Best > > George > > > > > > *From:* Aaron Leventhal <aleventhal@google.com> > *Sent:* Tuesday, August 20, 2019 11:37 AM > *To:* public-publ-wg@w3.org > *Cc:* Joanmarie Diggs <jdiggs@igalia.com> > *Subject:* Running headers/footers / new version of DPUB-ARIA? > > > > Hi all, > > > > I'm wondering about the plans for doing DPUB-ARIA 2.0 as described under > the deliverables: > > https://www.w3.org/2017/04/publ-wg-charter/#deliverables > <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2017%2F04%2Fpubl-wg-charter%2F%23deliverables&data=02%7C01%7Cjjwhite%40ets.org%7Cba59d4f6e6f044acfd9908d726579a04%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637020030007316600&sdata=PTB8VcQ%2FW8W5fG01aBOpUEjbgqKo1vPm%2FXbLtjQo3LM%3D&reserved=0> > > > > Thanks for what DPUB-ARIA provides so far. Google Docs is going to be > using it to expose semantics for online word processing. We're > collaborating with AT vendors and other developers of online word > processors as well. > > > > One gap is running headers and footers: > https://github.com/w3c/dpub-aria/issues/10 > <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fdpub-aria%2Fissues%2F10&data=02%7C01%7Cjjwhite%40ets.org%7Cba59d4f6e6f044acfd9908d726579a04%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637020030007316600&sdata=e3ypq%2B6xcsXXGoZesjzAX7dFC%2BlLIPu74KxiX0YHuVE%3D&reserved=0> > -- hence the reason for my email and status check :) > > > > Thanks for any info, > > Aaron > > > > > ------------------------------ > > This e-mail and any files transmitted with it may contain privileged or > confidential information. It is solely for use by the individual for whom > it is intended, even if addressed incorrectly. If you received this e-mail > in error, please notify the sender; do not disclose, copy, distribute, or > take any action in reliance on the contents of this information; and delete > it from your system. Any other use of this e-mail is prohibited. > > > > Thank you for your compliance. > ------------------------------ > > > ------------------------------ > > This e-mail and any files transmitted with it may contain privileged or > confidential information. It is solely for use by the individual for whom > it is intended, even if addressed incorrectly. If you received this e-mail > in error, please notify the sender; do not disclose, copy, distribute, or > take any action in reliance on the contents of this information; and delete > it from your system. Any other use of this e-mail is prohibited. > > > > Thank you for your compliance. > ------------------------------ > >
Received on Thursday, 22 August 2019 15:00:57 UTC