WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF Help Desk

for

From: Philip Kiff
Date: Oct 7, 2017 9:11AM

Jon, I know about your PDF remediation videos because I stumbled across
them last year when I was trying to learn how to fix a few specific,
pesky PDF issues. I learned some valuable new things about PDFs by
watching them and by listening to your explanations. Thanks! And I know
that if you were to provide details of how to fix any specific issue in
a PDF that I would similarly find that explanation invaluable and
exhaustive in detail.

But regarding the question of how best to share advice about PDF
remediation, I'm not sure of the best approach and am still not
convinced that the GitHub or even the wiki approach is best. I've been
thinking of creating a website that was built specifically to store PDF
remediation advice. In terms of technology, I was thinking of using
Drupal to build it, because Drupal is a relatively accessible CMS with a
commitment to accessibility, and because it happens to be the system
that I use on other projects, so it would be fun and easy for me to use
building the site.

The focus of the website I have in mind would be to provide instructions
on how to remediate PDFs (and possibly other Office documents) by
providing practical instructions for any level of user. With space for
comments if people have alternate ideas. Though I think it will be hard
to move active discussion of PDF remediation from here in the WebAIM
forum to another location. For all its faults, the WebAIM list is
accessible and has been around forever in terms of Internet years. And
most of the people who you might want to get opinions from are already
here. It is hard to move a pre-existing community. A successful wiki
needs active participation from the community, which I think will be a
challenge. So I was thinking I would probably end up adding most of the
content to this remediation website myself - though I would welcome any
offers to help and provide site privileges to encourage such assistance.
The site would have the technology in place to become a community-driven
site, but it would not depend on the community to function as intended.

The reason I was thinking of a custom-built site, is that I'm imagining
a site where users could search and filter the instructions in a variety
of ways to best meet their needs, depending on their skill level and on
the software they have available. So, for example, you could search by
error message provided by the PAC. Or by error flag in Acrobat Pro. And
you could filter the instructions so you got the most efficient set
based on whether you have Acrobat Pro, axesPDF, or CommonLook Global
Access, or any combination of them. The instructions shown might be
different in each case. And in some cases, there might be two or three
different methods described.

I was also imagining a site that could be used by beginners or by
experts, so you could get basic, beginner advice on how to fix an issue
(by using Acrobat Pro's built-in TURO tools, for example), or you could
get more complex instructions for someone who is remediating files every
day and might want to directly edit the content tree (which I do with a
surprising frequency now, simply because I find it the most efficient 
way to fix certain issues).

This is I think a different direction and goal than the PDF Help Desk
you're describing, but I thought I'd throw it out to the list as it is
something I'm considering working on this fall, and may end up doing
regardless of whether the PDF Help Desk gets off the ground.

Phil.

On 2017-09-11 9:30 AM, Metzessible wrote:
> Hi Phil,
>
> Thanks for reaching out. Unfortunately, I've only got stupid, selfish
> reasons for using Github. Apologies this is so long, but I don't have time
> to edit it to make it shorter.
>
> To be honest, Github wasn't the natural environment I would have preferred
> either, but I honestly didn't have much time to make something different.
> When we moved to Western Massachusetts from Washington, DC, I sold all my
> furniture, telling my wife I'd make new furniture for us if she bought me a
> $3000 Sawstop. That was a year ago, stuff is still in boxes, and my wife is
> becoming less patient. Further, I didn't like the existing platforms.
>
> I made videos before joining TPG that took me forever. I just wanted to
> know how to use video and captioning software, so I made them to learn
> those applications. The videos are helpful, but Acrobat and Word have
> changed so much since then, they're a bit outdated. I can change them or
> edit as I see fit, but those bookshelves aren't going to make themselves.
> Also, video is only good if the person is well known as an authority on the
> subject. I specialize in a niche subject that most people tend to ignore.
> If you follow me on Twitter, you'd know I mostly complain about stuff and
> don't really use it to guide people to be better PDF craftspeople.
>
> Also, those videos on YouTube are long and technical and most likely raise
> questions instead of putting an end to confusion altogether. Which means
> that blogs, listservs, or wikis wouldn't work either. Sure, you can have
> discussions via comments or responses, but it's hard to track the context
> of things. Eventually information becomes terribly scattered and makes
> Twitter's threading system look appealing in comparison.
>
> The other problem specifically with Wikis is that they are only as good as
> the amount of citations they provide. As I said here and elsewhere, there
> is a lot of resources out there. Often it's conflicting advice, but
> sometimes it's mostly just a personal choice to use sketchy information
> aggregated by a trusted third-party. A perfect example is relying on the
> recommendations for remediating PDFs from WCAG. It relies on using specific
> proprietary technology to make a PDF instead of actually explaining how
> WCAG theoretically applies to this type of web content. Also, it leads one
> to believe that making accessible PDFs can only be accomplished by using
> Word. For example, I made a PDF/UA document from a terribly low resolution
> scanned image so a visually impaired buddy from SSB Bart could drink beers
> with us one day. That information is not in WCAG.
>
> I wanted a place for experts to share advice for what works for them. I
> also wanted a single place I can store my own advice for things I come
> across in the field. The focus is less on relying on the authority of a
> random reference, but instead about someone who has done it before.
> Accessibility specifications generally can be applied to something that is
> testable. So if advice doesn't work exactly as it's intended per a comment
> in Github, we can discuss it further.
>
> I like Github's project management tools. They're not great, but they might
> work well for this scenario. When I'm bored again, I can post examples of
> things that have worked for me in the Code section, and people can discuss
> those in the Issues section. I wouldn't talk about the readme file, because
> that thing is just to tell people what the heck this thing is.
>
> The thing about PDF is that no matter what the error is, the solution is
> generally the same no matter what. This is a bold claim to make, but
> everything is based on the file format specification. The problem is
> determining which problem is occurring in the first place. A 300 page PDF
> might seem like it's totally corrupt, but it could just be a parsing error.
> Adjusting a tag here or there might fix the whole thing.
>
> If we look at this resource like a QA/QC system for the file format itself,
> then we're tracking bugs on the process itself. Therefore logically people
> would be raising issues on the process of remediating the file format. At
> face value, everyone believes their problem is the first time it's
> happened. Chances are it's happened before and people just gave up before
> actually fixing it. Or worse, they fixed it and didn't tell anyone because
> there wasn't a place to share that information. Or even worse, posted it to
> StackExchange where it was promptly closed as an unrelated question because
> all the answers tell the original poster to Google the answer (which is how
> I usually find out that others have the same question as me - because I
> Googled it).
>
> Treat this resource like an unauthorized bug tracking system for a file
> format. The file format itself is an open standard, which means that no
> single entity is responsible for making changes to it. A community of
> remediation experts has as much right to make a claim that the only way to
> make it accessible as a company like Microsoft or Adobe does. When you
> raise an issue, raise it in the Issues section as though it existed in the
> Code area already. I'll be the Editor of this system, and be managed by the
> community who will decide I need to do something. And when they aren't
> getting what they want, they can branch this repo and make their own
> community of deviant PDF experts. It could be like WHATWG, but hopefully
> less drama.
>
> Anyway, if you feel that a Wiki is the best place for this content, that
> can be accomplished too. But I'm not a fan of that sort of collaboration
> myself. I think Github could be a good place to track the annoyances of
> working in this ridiculous file format for now.
>
> Hope this answers your question.
>
> Jon
>
> On Sun, Sep 10, 2017 at 5:47 PM Philip Kiff < <EMAIL REMOVED> > wrote:
>
>> I love the idea, Jon. I was looking for just such a resource when I
>> started remediating PDFs in earnest over the past couple years, and
>> would have loved to find an active, open community of PDF remediation
>> professionals.
>>
>> I've given some thought to how such a community might develop, and
>> Github isn't the first place that comes to mind - it seems like an
>> unintuitive place to locate such a resource. I've used github for years,
>> but I'm not even sure how you imagine someone will get started
>> contributing - create an issue and then comment on it? Are you looking
>> for pull requests to your readme?
>>
>> If the eventual goal is to create a wiki, then why not create a wiki
>> directly? Maybe I just haven't kept up on how different communities are
>> using Github as a tool.
>>
>> Phil.
>>
>> On 2017-09-09 12:47 PM, Metzessible wrote:
>>> Hi there,
>>>
>>> I got bored last night and started a new repo on my github to provide a
>> way
>>> for people to help other people make more accessible PDFs. You can find
>> it
>>> here (in it's beautiful, currently unpopulated state):
>>>
>>> https://github.com/metzessible/PDFHelpDesk
>>>
>>> I'm aware there's a lot of information out there on how to make PDFs
>>> accessible, but the resources tend to vary on what's important or
>> relevant
>>> in terms of document accessibility. It also seems like there's
>> conflicting
>>> information out there from experts on how to handle PDF in the first
>> place.
>>> I'm also aware that many accessibility experts simply advise doing
>>> something else instead. While that's great and all, PDFs are still being
>>> created resulting in a lot of terrible documents out there.
>>>
>>> Further, now that the ISO has released ISO 32000-2 (
>>> https://www.pdfa.org/publication/iso-32000-2-pdf-2-0/), the methods
>> that we
>>> use to tag PDFs are going to change eventually. This is bound to cause
>> more
>>> confusion, frustration, and gnashing of teeth. My hope is to create a
>>> helpful resource for people who perhaps help create a consensus for what
>> an
>>> accessible PDF is supposed to look like. It'll also be an inevitable
>> place
>>> for me to post examples of things I come across in the wild and how to go
>>> about fixing them.
>>>
>>> Hopefully this will become a decent place for those stuck remediating
>>> documents with little to no guidance, since ignoring it for so long
>> hasn't
>>> really made the problem of inaccessible PDFs go away. In any case,
>>> hopefully I'll figure out how to actually use Github a bit better to make
>>> the most of it. I'm open to suggestions, and apologies in advance for the
>>> snark in the readme.
>>>
>>> Cheers,
>>> Jon Metz
>>> >>> >>> >>> >> >> >> >> >>
>>
> > > >