Re: PDF Technology Notes -- Re: 9 June 2011 Agenda ==============================

  Comments below preceded with "SLH"

On 6/9/2011 8:44 AM, chris@e-beer.net.au wrote:
>>    Dear WCAG WG,
>>
>> I appreciate the recent edits to the draft PDF Technology Notes at
>> <http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110310/pdf_notes.html>.
>> Additional edits that I suggest are described below:
>>
>> 1. Current wording: "Producing PDF Files That Support Accessibility"
>>
>> Issue: Currently it is not possible to produce PDF files that support the
>> accessibility needs of some people with low vision.
>>
>> Suggested wording: "Producing More Accessible PDF Files"
>> OR "Producing PDF Files that are More Accessible"
>> OR "Producing PDF Files that Better Support Accessibility"
>> OR "Producing PDF Files with Better Support Accessibility"
> I agree with that observation. In addition, reading the section in
> context, how would people feel about "PDF File Production and
> Accessibility" - it's nice and neutral (ie: makes no assumptions about the
> levels of accessibility PDF supports, and allows for progressive
> enhancement as the technology improves in a11y support) and it (from a
> technical document point of view) better describes the section in that the
> section doesn't actually tell you how to how to do something or describe a
> process (as is inferred by the current heading or Shawn's suggestions)
> rather it talks about production and and associated accessibility tools in
> the abstract sense.

SLH:  "PDF File Production and Accessibility" is even better from my perspective.


>> 2. Current wording: "PDF Authoring Tools that Support Accessibility"
>>
>> Issue: (same as above) "Support Accessibility" sounds like it covers all
>> accessibility issues.
>>
>> Suggested wording: "Authoring Tools that Produce Tagged PDF"
>> (If above not acceptable, possibly "PDF Authoring Tools with Accessibility
>> Support" wouldn't have the same implications of accessibility for all.)
> Again agree - also I do find it kind of weird that a) checking and repair
> is considered separate to production b) that Acrobat Pro isn't listed with
> the tagged PDF tools and c) isn't repair by inference suggesting that it
> has the ability to change content and therefore author?
>
> So I would suggest either "Authoring Tools which can be used with the
> Sufficient Techniques: ((link to the ST's), and then sub group these into
> editing and tagging tools, and checking tools. Even better - create a
> matrix of tools and the functions they support to avoid needless
> duplication.
>
>>
>> 3. Current wording: "An accessibility application can extract the content
>> of a document for presentation to users with disabilities by traversing
>> the structure hierarchy and presenting the contents of each node."
>>
>> Issue: What is an "accessibility application" here? Really, you mean
>> screen reader, yes? Given that user agents and assistive technologies do
>> not currently provide the customization needed by some people with low
>> vision, I think it’s not appropriate to say "for presentation to users
>> with disabilities".
>>
>> Suggested re-wording: "For example, screen readers can extract the content
>> of a document by traversing the structure hierarchy and presenting the
>> contents of each node."
>> (I tried "For example, screen readers can extract the content of a
>> document for presentation to users who are blind by traversing the
>> structure hierarchy and presenting the co,ntents of each node." but that
>> leaves out sighted people who use screen readers because of cognitive
>> disabilities – but maybe OK since it starts with "For example". Also tried
>> "For example, screen readers can extract the content of a document by
>> traversing the structure hierarchy and presenting the contents of each
>> node auditorilyy." but that leaves out dynamic braille. If really don't
>> want to say screen readers, could say "some assistive technologies"...)
>>
>>
> How about: "PDF includes several features in support of accessibility of
> documents to users with disabilities. The core of this support lies in the
> ability to determine the logical order of content in a PDF document,
> independently of the content's appearance or layout, through logical
> structure and Tagged PDF. For this reason, producers of PDF files must
> ensure that all information in a document is reachable by means of the
> structure hierarchy. In doing so, assistive technologies can be used to
> present PDF to users in the much the same manner as they would access
> other formats such as HTML markup or document files."

SLH: First part seems good. However, "assistive technologies can be used to present PDF to users in the much the same manner as they would access other formats such as HTML markup or document files" does not work at all because of the low vision issue. It implies that people with disabilities can have PDF presented like HTML and document files, but we can't -- the latter two offer extensive flexibility in text customization but PDF currently offers insufficient text customization for many people. Could say, "some assistive technologies can provide information about the structured hierarchy of the document." or "people using some assistive technologies can get information according to the structured hierarchy of the document" or such (that includes "some"!).

Regards,
~Shawn


> ie: the focus isn't on the type of technology (or disability) rather than
> the standardization of the user experience across readable formats. This
> in a sense is the spirit of the discussions there have been around moving
> back to a more general technology agnostic approach - in these tech notes
> I feel the inference is that structural hierarchy in any content is a
> "good thing" for accessibility, which is how it should be.
>
>> 4. Current wording: "Xenos Axess™ for Accessible Statements - PDF
>> accessibility software solution that enables enterprises to produce
>> high-volume PDF documents that are accessible, using assistive technology,
>> and usable by visually-impaired customers. It integrates with an
>> organization's existing enterprise content management (ECM) infrastructure
>> to capture high-volume print streams and automatically transform them into
>> [begin change]tagged[end change] PDFs.
>>
>> Issue: Similar issue, especially with the phrase "usable by
>> visually-impaired customers" which just plain wrong. And given it’s
>> automatic, probably doesn't to alt text for images. Also, too salesy.
>>
>> Suggested re-wording: "Xenos Axess™ for Accessible Statements - PDF
>> software integrates with an organization's existing enterprise content
>> management (ECM) infrastructure to capture high-volume print streams and
>> automatically transform them into tagged PDFs."
>>
> Agree
>
>> LOW priority, but I’ll go ahead and mention it while I’m at it:
>> 5. Current wording: "PAW - PDF Accessibility Wizard for Microsoft Office
>> from Netcentric Technologies is an add-in to Microsoft® Word that makes it
>> possible to create tagged PDF documents. PAW provides tools to allow
>> content authors to run accessibility tests in the Microsoft Word
>> environment and to remediate accessibility issues, thus enabling
>> organizations to greatly improve the accessibility of both Word and PDF
>> documents."
>> Issue: Salesy.
>> Suggested re-wording: Delete the bit at the end: "thus enabling
>> organizations to greatly improve the accessibility of both Word and PDF
>> documents."
> Has anyone used this tech on the list? Or is it vendor claims?
>
> Cheers
>
> Chris
>
>

Received on Thursday, 9 June 2011 16:46:51 UTC