Re: Running headers/footers / new version of DPUB-ARIA?

I agree that page marks and running headers/footers are separate.

If I may, allow me to bring a publisher angle of view.

These notions come from text layout in pages.
In digital products, there are 2 cases : reflowable (layout on the fly by the reading system), fixed layout (print layout is preserved in the reading system).
Then in reflowable mode, the live page breaks are unknown in advance, they are calculated by the rendering engine.

Print page mark:
In publishers EPUB today, the content files contain markup for page marks to preserve print page numbers in the digital version of the book.
The admitted coding is :
<span epub:type="pagebreak" id="page_9" title="9" role="doc-pagebreak"/>
In parallel, a page list is built in the nav document as a list of links :

<li id="p4">
          <a href="chap1.xhtml#page_9">9</a>

</li>

This enables navigation and accessibility, and we put a11y metadata in EPUB with an explicit information on the print ISBN:

<meta property="schema:accessibilityFeature">printPageNumbers</meta>
<dc:source>urn:isbn :9782016269947</dc:source>

As content producers, we don’t manage the way these pages numbers are displayed. It belongs to the reading system.

Running headers/footers
In EPUB, we have no way today to mark some text as potential header or footer.
I personally  support the idea of doc-pageheader and doc-pagefooter that would be used to mark chapter titles for instance.

Then reading system would have to implement it to display the chapter title at the top of the screen.
This would be a better UX.
And could be made skippable for AT.

Hope this help.

Best,
Luc


De : Avneesh Singh <avneesh.sg@gmail.com>
Date : jeudi 22 août 2019 à 18:39
À : Brady Duga <duga@google.com>, Aaron Leventhal <aleventhal@google.com>
Cc : George Kerscher <kerscher@montana.com>, "White, Jason J" <jjwhite@ets.org>, Leonard Rosenthol <lrosenth@adobe.com>, W3C Publishing Working Group <public-publ-wg@w3.org>, Joanmarie Diggs <jdiggs@igalia.com>
Objet : Re: Running headers/footers / new version of DPUB-ARIA?
Renvoyer - De : <public-publ-wg@w3.org>
Renvoyer - Date : jeudi 22 août 2019 à 18:39


My main concern is about trying to combine page marks with headers/footers.
Page markers (doc-pagebreak) is used to navigate to location in the content. i.e. it is with respect to content.
But headers/footers in this discussion thread are with respect to pixel location of document.

These are two very different things from this perspective. If we can keep both things separate then it addresses my concerns.

With regards
Avneesh

From: Brady Duga
Sent: Thursday, August 22, 2019 21:25
To: Aaron Leventhal
Cc: George Kerscher ; Avneesh Singh ; White, Jason J ; Leonard Rosenthol ; W3C Publishing Working Group ; Joanmarie Diggs
Subject: Re: Running headers/footers / new version of DPUB-ARIA?

Well, I am not an aria expert, and this group isn't really chartered for epub work (unless it is? I can never keep my charters straight), but it might produce something in the future that does have support for running head/foot, so we shouldn't overly restrict ourselves. But it does seem to me that any future formats would want to have the same capabilities as a word processor when it comes to explicitly skipping or reading the running heads/feet.

On Thu, Aug 22, 2019 at 8:40 AM Aaron Leventhal <aleventhal@google.com> wrote:
Brady, that's great to know. And since we drop the headers/footers on export, it sounds like we already do the right thing?

Sounds like we only really need the ARIA for the web view, not the EPUB export.

Aaron

On Thu, Aug 22, 2019 at 11:32 AM Brady Duga <duga@google.com> wrote:
Docs does in fact have native epub export (File -> Download -> EPUB Publication), largely driven by Garth Conboy (also a co-chair of this group). However, there is currently no facility in epub to do dynamic page numbering, though of course implementations may generate them for their UI. In the past, dynamic page numbering that changes with reflow has been experimented with, but the community has largely moved to fixed page numbers. This allows a user to understand their location after eg text zoom (page 250 is always 50% of a 500 page book). The other common use is to share location information succinctly and precisely, eg "class, turn to page 250". It is unclear to me how important having a generated page number is. There is also no particularly good way to do running page-header/foot in epub, though a hacky facility to do it did exist at one point. Currently, running heads are dropped in Docs to epub export. Future work in this area will likely be done in collaboration with CSS, assuming we actually decide to do it.

On Thu, Aug 22, 2019 at 8:01 AM Aaron Leventhal <aleventhal@google.com> wrote:
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2017%2F04%2Fpubl-wg-charter%2F%23deliverables&data=02%7C01%7Claudrain%40hachette-livre.fr%7C2b3a145e6248490f129808d7271f4fee%7Cf881a2c50a89483181b1c7846c49594d%7C0%7C0%7C637020887749960708&sdata=i34F74bnrFjxKs3YJNwKZwz5UDOTjOR6Ix6lOPJFmXg%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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fdpub-aria%2Fissues%2F10&data=02%7C01%7Claudrain%40hachette-livre.fr%7C2b3a145e6248490f129808d7271f4fee%7Cf881a2c50a89483181b1c7846c49594d%7C0%7C0%7C637020887749970702&sdata=u%2Fs78j7DQAB8Ubhp7zHM1DDXN5NGjeac9Ot5lW6O02k%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.

________________________________