WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF Help Desk

for

From: Metzessible
Date: Oct 8, 2017 9:35AM

Hi Phil,

Thanks for the kind words about my videos. They're a bit outdated now, but
I've been thinking of ways to make them way shorter and more categorical
anyway. And the audio leaves much to be desired. But it's nice to hear
they're still helping other people.

I think what I liked about the github approach was how it equalized all the
submissions. No one would be the sole expert that people came to read from.
The last thing I wanted to do was create a Jakob Nielson style site where
someone was looking for some individual as some kind of authority on the
subject. He has a lot of great advice on his site, peppered with personal
opinions that are mistaken as factual. So you end up with a lot of
conversations elsewhere arguing in favor of some technique or process
because Jakob Nielson said it was how to do or not to do something (not
because it's correct, efficient, or even helpful).

For the most part, the solutions to a PDF can be replicated for every PDF
that has the same problem. The root cause of PDF problems usually come from
not understanding what the actual problem is.

Therefore, I was looking at Github as a way to report issues in a sole file
format rather than an individual document. Since people probably don't know
what the actual problem is, they'd report a "bug" and someone would either
answer it or point to the type of problem in the community built wiki. And
this is where I failed.

I should have populated the files section with the type of accessibility
considerations one is likely to come across, so people can report on that.
Does it seem to be something to do with text (spaces in words when reading
with JAWS), images (what's the difference between actual text and
alternative text/ what the heck is E text??), links (links being read
twice), etc. Then report an issue on that specific area.

As the questions got populated with clearly satisfying answers based on
voting, they'd get written into the wiki. If people wanted to bore
themselves by reading even more text, then the wiki is the place to go.

I chose github, because most PWD I work with seem to be able to use it.
It's not the most usable site, especially for my particular disability, but
it seemed like a good community approach to solving a problem. I wanted a
solution to an accessibility problem that was implemented because a
majority of people feel it was a good solution, not because Jon Metz thinks
this is the answer.

I think inherently that's the problems you'll end up having with your site,
as you've proposed the solution. There's already a ton of sites out there
giving advice for web a11y. No matter what, each of those sites comes
across as the expert when they explain how to do something.

And when people disagree, they chat about it endlessly on places such as
private forums, like Skype or Slack; to Twitter and Facebook. And it
becomes a debate where the answer is muddled and unhelpful. As a community
of experts, I think this is a huge reason why accessibility is so danged
hard to do from non-experts.

That said, I wasn't trying to divert people from using excellent resources
that currently exist, like webaim or any other list serv. But there's no
value system in place other than lengthy disagreements about what makes
something accessible or not.

If you want to make a site, more power to you. I totally did not want to
spend time doing something else, mostly because of the fact I'm lazy. If
you want some suggestions, I'll totally help out where I can, but
truthfully, I don't have the time, experience, or money to do something
like that on my own.

I'll work on the PDF Help Desk A bit over the next week and see if I can
address the issues people are concerned about here. I just want something
that people find helpful and usable. We all know PDFs suck. I'm just trying
to make them suck less.

Thanks for the input, and continuing the conversation.

Best,
Jon

On Sat, Oct 7, 2017 at 11:11 AM, Philip Kiff < <EMAIL REMOVED> > wrote:

> 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
>>>> >>>> >>>> >>>> >>>>
>>> >>> >>> >>> >>>
>>>
>>> >> >> >> >>
>
>