Re: Should PDF documents have headers and footers on every page?

>So this issue is very much a user preference and thus flexibility should
be afforded to the user to choose which way they want information provided.

Unfortunately, it's not in the user's control to toggle the header/footer
from being an artifact or not. So I think we should provide advice to
authors, because they seldom know the requirements of screen reader users...

If possible I'd rather not contradict the PDF/UA because that just creates
headaches for authors who are under both standards. Unity where possible,
and when it's not possible we should document why authors should do
something different.

Jonathan, you brought up a good point about PDF documents that don't have
source documents but need to be remediated, (e.g., cannot add section
headings).

Anyway, perhaps it's not possible to unify with the PDF/UA on this... I've
tried my best here, I'm open to others opinions...

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Wed, Jun 10, 2015 at 2:35 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

>  Ø  This seems the same to me, titles, footers, and page numbers should
> be identifiable as such, but taking them out of the linear reading sequence
> doesn’t make a whole lot of sense to me.
>
>
>
> It’s also been my experience that screen reader find commands only work
> within a PDF page.  Furthermore, PDF readers may only deliver documents a
> page at a time for accessibility purposes for large documents.  Visually
> and with a screen reader I tend to deal with pages a single units and move
> between pages using control+pageUP and control+Pagedown.  While some users
> may just read through documents straight I personally find better
> comprehension and flexibility by reading with paragraph commands.  So this
> issue is very much a user preference and thus flexibility should be
> afforded to the user to choose which way they want information provided.
>
>
>
> Jonathan
>
>
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com
>
> Phone 703.637.8957
> Follow us: Facebook <http://www.facebook.com/#!/ssbbartgroup> | Twitter
> <http://twitter.com/#!/SSBBARTGroup> | LinkedIn
> <http://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>
>
>
>
> *From:* Hoffman, Allen [mailto:allen.hoffman@hq.dhs.gov]
> *Sent:* Wednesday, June 10, 2015 2:27 PM
> *To:* Gregg Vanderheiden; David MacDonald
> *Cc:* GLWAI Guidelines WG org
> *Subject:* RE: Should PDF documents have headers and footers on every
> page?
>
>
>
> My experience is that page titles and numbers are on the page and should
> be read when reading linearly.  Its just the is there and changing it as a
> convenience for leisure reading just doesn’t make sense to me for all
> materials.  It is something experienced speech listeners get used to.  When
> I was a Braille proofreader in my past life we used to fix even print
> errors as if blind readers would completely lose it if they found something
> strange in their reading, while the rest of the readership would just go on
> and accept it as an error.  This seems the same to me, titles, footers, and
> page numbers should be identificable as such, but taking them out of the
> linear reading sequence doesn’t make a whole lot of sense to me.
>
>
>
>
>
> *Allen Hoffman*
>
> Deputy Executive Director
>
> The Office of Accessible Systems & Technology
>
> Department of Homeland Security
>
> 202-447-0503 (voice)
>
> allen.hoffman@hq.dhs.gov
>
>
>
> DHS Accessibility Helpdesk
>
> 202-447-0440 (voice)
>
> 202-447-0582 (fax)
>
> 202-447-5857 (TTY)
>
> accessibility@dhs.gov
>
>
>
> *This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain sensitive and
> legally privileged information. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution, use or copying of this message is strictly prohibited.  If
> you have received this message in error, please reply immediately to the
> sender and delete this message.  Thank you.*
>
>
>
> *From:* Gregg Vanderheiden [mailto:gregg@raisingthefloor.org
> <gregg@raisingthefloor.org>]
> *Sent:* Wednesday, June 10, 2015 2:13 PM
> *To:* David MacDonald
> *Cc:* GLWAI Guidelines WG org
> *Subject:* Re: Should PDF documents have headers and footers on every
> page?
>
>
>
> Hi David
>
>
>
> No I was not worried that it would affect WCAG2ICT.    I was saying that
> the WCAG Working group (in WCAG2ICT   WCAG working group note) had stated
> that the proper way to interpret wcag when applying it to a document was to
> replace web page with  document.     Any other advice now would contradict
> the previous interpretation by the working group -   and that would both
> lead to confusion and also create problems in interpreting other success
> criteria.   It shouldn’t be interpreted one way on one SC and a different
> way for the other SC.   After studying all the SC  the WCAG task force and
> the WCAG Working Group confirmed - that the proper way to interpret WCAG
> for documents was to treat the document as a web page.
>
>
>
> RE the two techniques…..
>
>
>
> I think that most people reading through a document think of the headers
> and footers as “artifacts” in the PDF meaning of the word - which is text
> that is not part of the content stream.     It is very confusing when
> reading a page to have the headers and footers read in the middle of the
> sentence when the sentence spans the page break.    Drove me crazy the
> first time I encountered it and still is hard to deal with - and breaks the
> flow of the document when listening in audio.
>
>
>
> I don’t understand when you say "We can't pretend the page numbers in the
> PDF don't exist, can we?”   You can use them to jump around in the
> document easily (and the way to do this would not be to listen for them in
> the running text).
>
>
>
> I think if someone wants to know what the title of the document is - they
> can ask for that from the document as a whole and do not need to hear it
> again for each page.     Wouldn’t they?  the same way you do on a web page?
>
>
>
> I have heard different opinions from different screen-reader users about
> how much of a problem reading the titles is or isnt.   Some say they can
> work around hearing the page headers and numbers as part of the reading of
> the page.  Others do not like this and find it confusing.     I THINK there
> area ways to ask for page numbers  - without having them read to you in the
> sentence when crossing page boundaries.    Allen - can you confirm this for
> your screen reader?
>
> (behavior may change between screen readers and settings too).
>
>
>
>
>
> So that was the thought.
>
>
>
> anyone have different experiences?  or thoughts?
>
>
>
>
> *gregg*
>
>
>
> ----------------------------------
>
> Gregg Vanderheiden
>
> gregg@raisingthefloor.org
>
>
>
>
>
>
>
>  On Jun 9, 2015, at 8:45 PM, David MacDonald <david100@sympatico.ca>
> wrote:
>
>
>
> Hi Gregg
>
> Are you concerned that this recommendation could confuse our mapping of a
> full PDF document to a web page for WCAG (WCAG2ICT)? I don't really see it
> that way. I think our WCAG2ICT is fine and stable and not affected.
>
> People will refer to "pages" of this PDF "web page" the same way that they
> might refer to any other Section  of a document, and we have existing
> techniques to do that currentlyPDF17, PDF14. We can't pretend the page
> numbers in the PDF don't exist, can we? It is visually presented and we
> need to make a way to programmatically expose it without annoying screen
> reader users with all kinds of redundancy and interruptions.
>
> Our current advice in PDF14 contradicts itself. It advises authors to make
> headers and footers (and page numbers) available to screen readers using
> the MS Word footer tags, which actually turns them into artifacts that are
> ignored by screen readers. We also say use "pagination artifacts which are
> also ignored. So we look pretty dumb I think. In the same sentence saying
> to do something to make it programmatically accessible which renders it NOT
> programmatically accessible.
>
> I'm simply suggesting we clean up the language, be more specific, and
> coordinate with the PDF/UA on this particular issue. I don't think this any
> way compromises WCAG2ICT or changes the definition of the Web Page under
> the WCAG. It exposes information in an accessible and elegant way by
> syncing pages using PDF17 Technique and marking headers and footers up as
> artifacts, and providing important information on the Title page, and
> section headings, so screen reader users know what is going on.
>
>
>
>
>    Cheers,
>
> David MacDonald
>
>
>
> *CanAdapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
> On Tue, Jun 9, 2015 at 7:47 PM, Gregg Vanderheiden <
> gregg@raisingthefloor.org> wrote:
>
> For documents - a full document is equated to a web page.  See WCAG2ICT
> report.
>
>
> *gregg*
>
>
>
> ----------------------------------
>
> Gregg Vanderheiden
>
> gregg@raisingthefloor.org
>
>
>
>
>
>
>
>  On Jun 9, 2015, at 4:12 PM, David MacDonald <david100@sympatico.ca>
> wrote:
>
>
>
> I have compared what PDF/UA with WCAG say about headers and footers and
> have written up a small report and recommendations on how I think we should
> proceed with Headers and Footers in PDF documents.
>
> http://davidmacd.com/blog/pdf-headers-footers.html
>
> I think PDF14 requires an update quickly. I could take an action item to
> propose the rewrite.
>
>
>
>
>    Cheers,
>
> David MacDonald
>
>
>
> *CanAdapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
> On Mon, May 18, 2015 at 9:54 PM, Jonathan Avila <
> jon.avila@ssbbartgroup.com> wrote:
>
> David, there are some good but very specific reasons to not artifact
> header and footer information.  Otherwise running headers and footer should
> be made pagination artifacts and the Page Labels feature should be used to
> add Page numbering including section information to identify pages and
> sections to assistive technology.  The page label feature is pretty
> powerful and allows flexibility for different number schemes such as Roman
> numbers and custom label prefixes.
>
>
>
> Some instances of header and footer information that might be useful
> include classification information on classified documents, copyright
> information, form numbers, or other content that is not located elsewhere
> in the document.  In general I recommend marking that content as
> non-artifact content on the first and last page so it does not break up the
> reading order of content.
>
>
>
> Best Regards,
>
>
>
> Jonathan
>
>
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com
>
>
>
> 703-637-8957 (o)
> Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter
> <http://twitter.com/#%21/SSBBARTGroup> | LinkedIn
> <http://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* Monday, May 18, 2015 2:50 PM
> *To:* WCAG
> *Subject:* Should PDF documents have headers and footers on every page?
>
>
>
>
>
> We have a technique for Creating PDF headers and footers, usually inserted
> using the source program such as MS Word Headers and Footers. See PDF14.
>
>
>
> http://www.w3.org/TR/WCAG20-TECHS/PDF14.html
> This causes the screen reader to announce these Headers and footers at the
> top and bottom of every page. Sometimes the interrupt reading halfway
> through a sentence that continues on the following page. I can imagine this
> is quite annoying for screen reader users tp have to listen through a
> header and a footer between every page.
>
> Visually we just skip over it... Usually most of the information found in
> the header and footer is available on the home page of the document or some
> other prominent place.
>
> What is useful is page numbers. However, if the author syncs the page
> numbering of the PDF with the document large numbers using PDF17, it makes
> me wonder if we should advise the author to mark headers and footers as
> artifacts instead...
>
> An organization that teaches PDF, which is fairly well known, and has done
> work for Adobe teaches to turn these headers and footers into artifacts so
> they will be ignored by a screen reader.
>
> I propose we place a note on PDF14 saying something like this:
>
>  "If the page numbering has been synchronized as in PDF17 and other header
> and footer information is available in a prominent place in the document
> such as a heading or home page, then headers and footers are not necessary
> and can be marked up as artifacts..."
>
> Cheers,
>
> David MacDonald
>
>
>
> *CanAdapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
>
>
>
>
>
>

Received on Wednesday, 10 June 2015 20:17:43 UTC