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

And Charles LaPierre just reminded me that we're no longer
recommending @title; instead @aria-label should be used for that. Duh, I
knew that! Thanks, Charles.

The pagebreak marker was designed to be very precise, simply to mark a spot
corresponding to a page break in a *print version* of a publication. It was
not intended to govern rendering or pagination digitally. It was created to
enable a person using a reflowable digital version (whether with AT or not)
to be able to locate a citation, cross reference, or back-of-the-book index
entry, or to follow the instruction from a teacher to "turn to page 53" or
"read pages 26-44 by Tuesday" when (as is often the case today) there is a
referenceable print version, e.g., a print book for which those references
are no more precise than identifying the print page on which those things
fall. Its motivation was mainly for accessibility. Its purpose was to
locate the print page break, not to announce it. I believe the recommended
markup accomplishes that.

So Aaron, since what you're really working on is rendering (and great to
hear you're doing this work for Google Docs!!!), you probably need entirely
different markup for that. The dpub-pagebreak was really for the use case
described above; at least that's what it was originally created for.
(Somebody more technical than me--e.g., Charles--can say whether there is
any other RS behavior associated with it now, especially wrt dynamic
pagination, that I'm not aware of.) Which gets us back to your original
question, which actually wasn't about the page breaks, it was about headers
and footers. :) I just wanted to make sure the two weren't going to get
conflated or confused.

On Wed, Aug 21, 2019 at 11:42 AM Aaron Leventhal <aleventhal@google.com>
wrote:

> As far as having the page number be right at the page break, I think if we
> have a doc-pagenum role the AT can decide when the best time is to provide
> that info. It might be when the user is navigating in the middle of a page,
> and the user asks for positional info (page/col/line). Having it be as the
> @title of the doc-pagebreak doesn't seem particularly semantic to me. How
> do we know it's really a page number and not some tooltip the author wants
> to surface? I prefer we clarify exposing of page numbers and consider a
> role for it, and/or relationship as suggested by Jason.
>
> Yep, agree on rendered vs. sequential page number. The user agent might be
> able to compute the sequential page number based on the number of page
> breaks, although I'm not sure how performant that would be. How important
> is it for users to get both kinds of page numbers? I think that might be
> confusing. Would be good to know what MS Word does.
>
> Aaron
>
> On Wed, Aug 21, 2019 at 11:23 AM Bill Kasdorf <kasdorf.bill@gmail.com>
> wrote:
>
>> The pagebreak marker as specified in EPUB  was intentionally an empty
>> phrase-level element so that it can be placed before the first word on the
>> indicated page. It should be agnostic whether the pages are fixed or
>> reflowing. If fixed, and if the folio (the page number) needs to be
>> rendered, then that requires other markup because <span id="pg04"
>> role="doc-pagebreak" title="4">4</span> wouldn't be sufficient.
>>
>> One other nuance: the folio (the rendered page number) is not necessarily
>> the same as the sequential position in the publication. Most books number
>> frontmatter with roman numerals. So for that page 4 example, if it's in a
>> book with twelve pages of frontmatter, you would more likely have <span
>> id="pg16" role="doc-pagebreak" title="4"/>: the folio of the 16th page is 4.
>>
>> On Wed, Aug 21, 2019 at 10:56 AM Leonard Rosenthol <lrosenth@adobe.com>
>> wrote:
>>
>>> I’m in agreement with you on this one Aaron.  Page number is completely
>>> separate from the page break, because (as you note) they can appear
>>> (visually) at various spots in the content that have nothing to do with
>>> break points…
>>>
>>>
>>>
>>> Leonard
>>>
>>>
>>>
>>> *From:* Aaron Leventhal <aleventhal@google.com>
>>> *Sent:* Wednesday, August 21, 2019 10:27 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?
>>>
>>>
>>>
>>> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2017%2F04%2Fpubl-wg-charter%2F%23deliverables&data=02%7C01%7Clrosenth%40adobe.com%7C8755096534af4c7297cb08d726439a64%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637019944112968109&sdata=R0qzNRVjN8BlA6%2FZHoQfgBsQ7pA%2BmBbh5LIqvG3EWeE%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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fdpub-aria%2Fissues%2F10&data=02%7C01%7Clrosenth%40adobe.com%7C8755096534af4c7297cb08d726439a64%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637019944112978102&sdata=aeFpfEGHaA6A6VB1SZ05dvknCCVQDGqPtVGqfLbZoyU%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.
>>> ------------------------------
>>>
>>>
>>
>> --
>> *Bill Kasdorf*
>> *Principal, Kasdorf & Associates, LLC*
>>
>> *Founding Partner, Publishing Technology Partners
>> <https://pubtechpartners.com/>*
>> kasdorf.bill@gmail.com
>> +1 734-904-6252
>>
>> ISNI: http://isni.org/isni/0000000116490786
>> ORCiD: https://orcid.org/0000-0001-7002-4786
>> <https://orcid.org/0000-0001-7002-4786?lang=en>
>>
>>

-- 
*Bill Kasdorf*
*Principal, Kasdorf & Associates, LLC*

*Founding Partner, Publishing Technology Partners
<https://pubtechpartners.com/>*
kasdorf.bill@gmail.com
+1 734-904-6252

ISNI: http://isni.org/isni/0000000116490786
ORCiD: https://orcid.org/0000-0001-7002-4786
<https://orcid.org/0000-0001-7002-4786?lang=en>