WebAIM - Web Accessibility In Mind

E-mail List Archives

PDF Help Desk

for

From: Metzessible
Date: Sep 28, 2017 1:22PM


OK, I'll look into a wiki site instead.

On Tue, Sep 19, 2017 at 4:22 PM, Jim Homme < <EMAIL REMOVED> > wrote:

> Hi,
> A Jekyll site hooked to a Disqus forum may work for something like this.
> You could accomplish this with GitHub. You could even point the site at a
> domain name.
>
> Jim
>
>
> =========> Jim Homme,
> Team Lead and Accessibility Consultant,
> Bender HighTest Accessibility Team
> Bender Consulting Services, Inc.,
> 412-787-8567,
> <EMAIL REMOVED>
> http://www.benderconsult.com/our%20services/hightest-
> accessible-technology-solutions
> E+R=O
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Ryan E. Benson
> Sent: Monday, September 18, 2017 8:57 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] PDF Help Desk
>
> Jon, A wiki is probably the easiest way to keep updated, unless you want
> to set up a Jekyll site via GitHub.
>
> --
> Ryan E. Benson
>
> On Mon, Sep 11, 2017 at 9:30 AM, Metzessible < <EMAIL REMOVED> >
> 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
> > > > > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > > >
> > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > >
> > >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > at http://webaim.org/discussion/archives
> > > > > >