E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Metzessible
Date: Thu, Sep 28 2017 1:22PM
Subject: PDF Help Desk
No previous message | Next message →

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

On Tue, Sep 19, 2017 at 4:22 PM, Jim Homme < = EMAIL ADDRESS 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 ADDRESS REMOVED =
> http://www.benderconsult.com/our%20services/hightest-
> accessible-technology-solutions
> E+R=O
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Ryan E. Benson
> Sent: Monday, September 18, 2017 8:57 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > > >

From: Jim Homme
Date: Mon, Oct 02 2017 1:27PM
Subject: Re: PDF Help Desk
← Previous message | Next message →

Hi,
GitHub repositories come with Wiki's.

Thanks.

Jim


=========Jim Homme,
Team Lead and Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Metzessible
Sent: Thursday, September 28, 2017 3:22 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] PDF Help Desk

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

On Tue, Sep 19, 2017 at 4:22 PM, Jim Homme < = EMAIL ADDRESS 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 ADDRESS REMOVED =
> http://www.benderconsult.com/our%20services/hightest-
> accessible-technology-solutions
> E+R=O
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Ryan E. Benson
> Sent: Monday, September 18, 2017 8:57 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > > >

From: Philip Kiff
Date: Sat, Oct 07 2017 9:11AM
Subject: Re: PDF Help Desk
← Previous message | Next message →

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

From: Metzessible
Date: Sun, Oct 08 2017 9:35AM
Subject: Re: PDF Help Desk
← Previous message | No next message

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