WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: PDF on websites + PDF is *not* accessible

for

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

From: Andrew Kirkpatrick
Date: Mon, Jul 08 2013 10:53AM
Subject: PDF on websites + PDF is *not* accessible
No previous message | Next message →

Last week was obviously a great week to have been on vacation... :)

I do take exception to a couple of minor things in the thread, but mostly the statement "Accessibility of PDF has largely focused on screen reader access for users who are blind" which is just not true. The Acrobat and Reader teams have worked to provide features for blind users, true, but also features to support low vision users (not as many as some would like, as stated) such as the zooming and reflow support and support for different high-contrast modes, support for keyboard-only users, and support for various OS-level conventions that users with different disabilities rely on. Also, it is important to recognize that what we're talking about now is not PDF but PDF viewers.

As always, I'm happy to discuss issues and ideas that people have to improve their experience with PDF. (BTW, Shawn, you should fix my email address on your site - please use the official feedback form http://www.adobe.com/accessibility/feedback.html which goes to me and my team).

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility


From: Duff Johnson
Date: Tue, Jul 09 2013 9:51AM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

Shawn,

You've called out PDF as a format for specific comment. You've made several assertions pertaining to technical and practical realities.

While I deeply respect your perspective and the conversation thus far not all statements have been accurate, informative or helpful.

This is an important forum, and I want to put the record straight.

A summary of my extended response (see below) is this:

- Shawn's confusing the PDF format itself with software implementations thereof. Contra her claim, this is the fundamental "misnomer" at hand in the discussion.

- In WCAG 2.0 terms Shawn's conflating "accessibility" with "accessibility-supported." They are rightly distinct; collapsing the distinction does not serve understanding or drive solutions to improve PDF accessibility.

- Such confusion is *naturally* understandable for end-users. Informed advocates, however, need to respect these critical distinctions to be maximally effective in terms of influencing software development - the aforementioned "implementations."

- The work Shawn's doing with TAdER is a superb contribution to critical, practical information for any developer working on user experience - including those focussed on making electronic documents accessible. The project would be more successful if it refrained from inaccurate generalizations while making technical claims.

> Background from previous comments is below [1].
>
> The problem is that PDF is currently *not sufficiently accessible* to many people with low vision, dyslexia, and related conditions and situations that impact reading - because Adobe Reader and other PDF viewers lack sufficient text customization functionality.

First, this statement is equally true for plenty of implementations of HTML / CSS / JavaScript technology, various combinations of which produce results that defeat today's AT technologies. It's hardly a "PDF problem" - calling out PDF specifically in this case is misleading.

That said, if plain HTML can meet TAdER requirements then it's hard to understand why PDF/UA doesn't as well since PDF/UA files may be readily exported to plain HTML while (key point!) retaining the ability to fallback to the real document.

The later point, however, is that you cannot reasonably claim there's any misnomer in describing properly-tagged (PDF/UA-1) files as "accessible". They are accessible within any reasonable definition that you'd apply to WCAG 2.0 conforming HTML.

But that's not my core point, which is that categorical statements such as you've offered are actually and notably injurious to the cause of promoting development in accessibility technology. You won't win new software development efforts by attacking the file-formats themselves.

Look at it this way: Accessible alternatives to PDF files will depend in the real-world on re-use of PDF content because it is the only available content in many given situations. Lots of stuff is in PDF for reasons that just make sense to the players at hand in their respective business contexts, and that's the reality with which you need to engage.

Having accepted it one ought (it seems to me) focus on highlighting the *lack* of technical barriers to full access to PDF, the degree of standardization available, the extent of implementation tools from PDFlib, iText, Adobe, Microsoft and others. Give developers reasons to invest in accessibility tools; do not foreclose on the potential for investment by proclaiming that somehow alternatives must be provided!

When tagging or re-use fails a given user for a given reason, why, the PDF is the *critical* backup, tedious as it make be, it's still the *actual* document.

That's the PDF focus and value-proposition, and it's got nothing to do with the ability to adjust kerning for X percent of users who need such. Equal access to the *same* content is - or ought to be - the focus here. There's no technical barrier to full accessibility (including TAdER parameters) to content delivered in PDF, and you do the community a disservice when you suggest otherwise.

You would achieve far more, I think, by making statements similar to the following:

"PDF files can only be considered fully accessible in every possible use-case when full TAdER text management is available."

Only when you are using such constructive terms will you will then be helping, rather that hurting, the cause of improving access to content that exists (fact) in PDF.

> Even well tagged PDF that is more accessible to screen reader users is still *not accessible* to many people with other print disabilities. Accessibility is more than screen reader access.

This is a straw-man. No-one claims this for PDF any more than for HTML.

> Unfortunately, "tagged PDF" started getting called "accessible PDF" -- that is inaccurate and a harmful misnomer.

Let's be completely clear on this.

PDF that conforms with PDF/UA-1 (ISO 14289-1) is accessible, period. Whether it is accessibility-supported for any given need is *another matter* - a question for implementers, but assuredly not in question with respect to the file format.

If vanilla HTML meets TAdER or TAdER-relevent standards for accessibility, then it's fair to say that PDF can qualify, because PDF/UA-1 conforming PDF files can be exported to the user's chosen HTML implementation. As you rightly point out, forms aren't yet supported in VIP Reader. Why is this more worthy of note that X, Y or Z failure of FaceBook, or iTunes or whatever to accommodate TAdER preferences?

Do you really want to suggest that PDF is inaccessible now but can "become accessible" when (for example (VIP Reader adds the ability to print? C'mon.

Now, anyone can and will concede that it's also possible to simply "tag" PDF without doing it well, just as its possible to do a half-ass job of ensuring CSS usage is accessible (for example). Tagging is a critical but insufficient part of meeting accessibility requirements for PDF content. Tell them that, instead of trying to make an (incorrect) grossly general claim about the file-format as a whole.

> It perpetuates the lack of awareness, even among accessibility specialists, that PDF is actually not accessible to many people with print disabilities.
>
>> My job is to communicate one person's ideas to another person.
>> I want to provide what is both legally required and what is desirable to the users.
>
> While PDF is a useful medium for some situations; when it is used, there must be a more accessible alternative provided in order for the information to be available to people with disabilities.

Once upon a time this was true. Today, this claim is inaccurate as written. It would be much more useful if it were re-written as follows (for example):

"While PDF is a vital medium for many situations; when it is used, PDF creation, editing or reading software should create or read PDF/UA in order to generate or provide appropriate alternative representations of the PDF's content in order for that PDF's actual and inherent content to be available to the greatest possible number of people with disabilities."

> I've been fairly quiet about this for many years (except to Adobe product managers :) because the accessibility of PDF has improved from years ago, but I'm deeply concerned about the *misconception that PDF is accessible*.

PDF *can* be made accessible, and at this level of generalization, it's absurd to highlight PDF in format terms. Plenty of large-scale HTML implementations don't meet your preferred specifications for full accessibility today but I don't see you calling out HTML per se as "inaccessible."

> For more info, please see:
> * Text Customization for Readability <http://www.tader.info/>;

I commend you for this site, and would unreservedly recommend that reader software implementers - regardless of medium - review your substantive recommendations for UI controls in readers.

> * PDF viewers section of Support for Text Customization <http://www.tader.info/support.html#PDFisNOTaccessible>;
>
> (That is a work in progress and I welcome feedback directly.)

Well, I've been no less public that you, I guess, with my opinion! ;)

Duff.

From: Ryan E. Benson
Date: Tue, Jul 09 2013 4:13PM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

Duff said:
First, this statement is equally true for plenty of implementations of HTML
/ CSS / JavaScript technology, various combinations of which produce
results that defeat today's AT technologies. It's hardly a "PDF problem" -
calling out PDF specifically in this case is misleading.

Duff this is incorrect. I can open up most browsers and define a user
stylesheet which allows me to do about anything I wish provided that I
understand CSS. Either by default, or via plugins, I can define a custom
stylesheet for a specific site. For example, in Firefox I have an outline
which makes it clear where the focus is. Of course there are ways
developers can get around my stylesheet.For example the Gmail UI likes to
use spans/divs instead of whatever a semantically appropriate tag would be.
In Acrobat, I can only choose from a few back/foreground colors.

--
Ryan E. Benson


On Tue, Jul 9, 2013 at 11:51 AM, Duff Johnson < = EMAIL ADDRESS REMOVED = > wrote:

> Shawn,
>
> You've called out PDF as a format for specific comment. You've made
> several assertions pertaining to technical and practical realities.
>
> While I deeply respect your perspective and the conversation thus far not
> all statements have been accurate, informative or helpful.
>
> This is an important forum, and I want to put the record straight.
>
> A summary of my extended response (see below) is this:
>
> - Shawn's confusing the PDF format itself with software implementations
> thereof. Contra her claim, this is the fundamental "misnomer" at hand in
> the discussion.
>
> - In WCAG 2.0 terms Shawn's conflating "accessibility" with
> "accessibility-supported." They are rightly distinct; collapsing the
> distinction does not serve understanding or drive solutions to improve PDF
> accessibility.
>
> - Such confusion is *naturally* understandable for end-users. Informed
> advocates, however, need to respect these critical distinctions to be
> maximally effective in terms of influencing software development - the
> aforementioned "implementations."
>
> - The work Shawn's doing with TAdER is a superb contribution to critical,
> practical information for any developer working on user experience -
> including those focussed on making electronic documents accessible. The
> project would be more successful if it refrained from inaccurate
> generalizations while making technical claims.
>
> > Background from previous comments is below [1].
> >
> > The problem is that PDF is currently *not sufficiently accessible* to
> many people with low vision, dyslexia, and related conditions and
> situations that impact reading - because Adobe Reader and other PDF viewers
> lack sufficient text customization functionality.
>
> First, this statement is equally true for plenty of implementations of
> HTML / CSS / JavaScript technology, various combinations of which produce
> results that defeat today's AT technologies. It's hardly a "PDF problem" -
> calling out PDF specifically in this case is misleading.
>
> That said, if plain HTML can meet TAdER requirements then it's hard to
> understand why PDF/UA doesn't as well since PDF/UA files may be readily
> exported to plain HTML while (key point!) retaining the ability to fallback
> to the real document.
>
> The later point, however, is that you cannot reasonably claim there's any
> misnomer in describing properly-tagged (PDF/UA-1) files as "accessible".
> They are accessible within any reasonable definition that you'd apply to
> WCAG 2.0 conforming HTML.
>
> But that's not my core point, which is that categorical statements such as
> you've offered are actually and notably injurious to the cause of promoting
> development in accessibility technology. You won't win new software
> development efforts by attacking the file-formats themselves.
>
> Look at it this way: Accessible alternatives to PDF files will depend in
> the real-world on re-use of PDF content because it is the only available
> content in many given situations. Lots of stuff is in PDF for reasons that
> just make sense to the players at hand in their respective business
> contexts, and that's the reality with which you need to engage.
>
> Having accepted it one ought (it seems to me) focus on highlighting the
> *lack* of technical barriers to full access to PDF, the degree of
> standardization available, the extent of implementation tools from PDFlib,
> iText, Adobe, Microsoft and others. Give developers reasons to invest in
> accessibility tools; do not foreclose on the potential for investment by
> proclaiming that somehow alternatives must be provided!
>
> When tagging or re-use fails a given user for a given reason, why, the PDF
> is the *critical* backup, tedious as it make be, it's still the *actual*
> document.
>
> That's the PDF focus and value-proposition, and it's got nothing to do
> with the ability to adjust kerning for X percent of users who need such.
> Equal access to the *same* content is - or ought to be - the focus here.
> There's no technical barrier to full accessibility (including TAdER
> parameters) to content delivered in PDF, and you do the community a
> disservice when you suggest otherwise.
>
> You would achieve far more, I think, by making statements similar to the
> following:
>
> "PDF files can only be considered fully accessible in every possible
> use-case when full TAdER text management is available."
>
> Only when you are using such constructive terms will you will then be
> helping, rather that hurting, the cause of improving access to content that
> exists (fact) in PDF.
>
> > Even well tagged PDF that is more accessible to screen reader users is
> still *not accessible* to many people with other print disabilities.
> Accessibility is more than screen reader access.
>
> This is a straw-man. No-one claims this for PDF any more than for HTML.
>
> > Unfortunately, "tagged PDF" started getting called "accessible PDF" --
> that is inaccurate and a harmful misnomer.
>
> Let's be completely clear on this.
>
> PDF that conforms with PDF/UA-1 (ISO 14289-1) is accessible, period.
> Whether it is accessibility-supported for any given need is *another
> matter* - a question for implementers, but assuredly not in question with
> respect to the file format.
>
> If vanilla HTML meets TAdER or TAdER-relevent standards for accessibility,
> then it's fair to say that PDF can qualify, because PDF/UA-1 conforming PDF
> files can be exported to the user's chosen HTML implementation. As you
> rightly point out, forms aren't yet supported in VIP Reader. Why is this
> more worthy of note that X, Y or Z failure of FaceBook, or iTunes or
> whatever to accommodate TAdER preferences?
>
> Do you really want to suggest that PDF is inaccessible now but can "become
> accessible" when (for example (VIP Reader adds the ability to print? C'mon.
>
> Now, anyone can and will concede that it's also possible to simply "tag"
> PDF without doing it well, just as its possible to do a half-ass job of
> ensuring CSS usage is accessible (for example). Tagging is a critical but
> insufficient part of meeting accessibility requirements for PDF content.
> Tell them that, instead of trying to make an (incorrect) grossly general
> claim about the file-format as a whole.
>
> > It perpetuates the lack of awareness, even among accessibility
> specialists, that PDF is actually not accessible to many people with print
> disabilities.
> >
> >> My job is to communicate one person's ideas to another person.
> >> I want to provide what is both legally required and what is desirable
> to the users.
> >
> > While PDF is a useful medium for some situations; when it is used, there
> must be a more accessible alternative provided in order for the information
> to be available to people with disabilities.
>
> Once upon a time this was true. Today, this claim is inaccurate as
> written. It would be much more useful if it were re-written as follows (for
> example):
>
> "While PDF is a vital medium for many situations; when it is used, PDF
> creation, editing or reading software should create or read PDF/UA in order
> to generate or provide appropriate alternative representations of the PDF's
> content in order for that PDF's actual and inherent content to be available
> to the greatest possible number of people with disabilities."
>
> > I've been fairly quiet about this for many years (except to Adobe
> product managers :) because the accessibility of PDF has improved from
> years ago, but I'm deeply concerned about the *misconception that PDF is
> accessible*.
>
> PDF *can* be made accessible, and at this level of generalization, it's
> absurd to highlight PDF in format terms. Plenty of large-scale HTML
> implementations don't meet your preferred specifications for full
> accessibility today but I don't see you calling out HTML per se as
> "inaccessible."
>
> > For more info, please see:
> > * Text Customization for Readability <http://www.tader.info/>;
>
> I commend you for this site, and would unreservedly recommend that reader
> software implementers - regardless of medium - review your substantive
> recommendations for UI controls in readers.
>
> > * PDF viewers section of Support for Text Customization <
> http://www.tader.info/support.html#PDFisNOTaccessible>;
> >
> > (That is a work in progress and I welcome feedback directly.)
>
> Well, I've been no less public that you, I guess, with my opinion! ;)
>
> Duff.
> > > >

From: Duff Johnson
Date: Tue, Jul 09 2013 4:47PM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

On Jul 9, 2013, at 6:13 PM, "Ryan E. Benson" < = EMAIL ADDRESS REMOVED = > wrote:

> Duff said:
> First, this statement is equally true for plenty of implementations of HTML
> / CSS / JavaScript technology, various combinations of which produce
> results that defeat today's AT technologies. It's hardly a "PDF problem" -
> calling out PDF specifically in this case is misleading.
>
> Duff this is incorrect. I can open up most browsers and define a user
> stylesheet which allows me to do about anything I wish provided that I
> understand CSS. Either by default, or via plugins, I can define a custom
> stylesheet for a specific site. For example, in Firefox I have an outline
> which makes it clear where the focus is. Of course there are ways
> developers can get around my stylesheet.

…and of course, there are ways in which PDF authors can get around making PDF files that can be effectively reused in the AT of choice as well!

But my point is that while it's quite horrendously easy to achieve inaccessible PDF that is emphatically not the same as "PDF is inaccessible."

> For example the Gmail UI likes to
> use spans/divs instead of whatever a semantically appropriate tag would be.
> In Acrobat, I can only choose from a few back/foreground colors.


Acrobat - proprietary application from Adobe Systems
PDF - open file-format

There's a difference!

My point is that a properly tagged PDF can - for these purposes - "become" an HTML file, and thus becomes susceptible to the sorts of enhancements you mention. pdfGoHTML demonstrates this fact, and it's free. Of course, it requires Acrobat, and doesn't (yet) work with Reader… but that's an implementation, not a file-format question.

I'm simply trying to ensure we distinguish between PDF and applications which create or process PDF. The distinction is *vital* if one wishes to inform and affect software development.

Duff.

From: Andrew Kirkpatrick
Date: Tue, Jul 09 2013 7:28PM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

In Acrobat, I can only choose from a few back/foreground colors.

[AWK] Ryan, In Acrobat/Reader you can get any colors you want. We provide a selection, but you can get as many colors as your OS supports if you select the option to use the system colors.
AWK


On Tue, Jul 9, 2013 at 11:51 AM, Duff Johnson < = EMAIL ADDRESS REMOVED = > wrote:

> Shawn,
>
> You've called out PDF as a format for specific comment. You've made
> several assertions pertaining to technical and practical realities.
>
> While I deeply respect your perspective and the conversation thus far
> not all statements have been accurate, informative or helpful.
>
> This is an important forum, and I want to put the record straight.
>
> A summary of my extended response (see below) is this:
>
> - Shawn's confusing the PDF format itself with software
> implementations thereof. Contra her claim, this is the fundamental
> "misnomer" at hand in the discussion.
>
> - In WCAG 2.0 terms Shawn's conflating "accessibility" with
> "accessibility-supported." They are rightly distinct; collapsing the
> distinction does not serve understanding or drive solutions to improve
> PDF accessibility.
>
> - Such confusion is *naturally* understandable for end-users. Informed
> advocates, however, need to respect these critical distinctions to be
> maximally effective in terms of influencing software development - the
> aforementioned "implementations."
>
> - The work Shawn's doing with TAdER is a superb contribution to
> critical, practical information for any developer working on user
> experience - including those focussed on making electronic documents
> accessible. The project would be more successful if it refrained from
> inaccurate generalizations while making technical claims.
>
> > Background from previous comments is below [1].
> >
> > The problem is that PDF is currently *not sufficiently accessible*
> > to
> many people with low vision, dyslexia, and related conditions and
> situations that impact reading - because Adobe Reader and other PDF
> viewers lack sufficient text customization functionality.
>
> First, this statement is equally true for plenty of implementations of
> HTML / CSS / JavaScript technology, various combinations of which
> produce results that defeat today's AT technologies. It's hardly a
> "PDF problem" - calling out PDF specifically in this case is misleading.
>
> That said, if plain HTML can meet TAdER requirements then it's hard to
> understand why PDF/UA doesn't as well since PDF/UA files may be
> readily exported to plain HTML while (key point!) retaining the
> ability to fallback to the real document.
>
> The later point, however, is that you cannot reasonably claim there's
> any misnomer in describing properly-tagged (PDF/UA-1) files as "accessible".
> They are accessible within any reasonable definition that you'd apply
> to WCAG 2.0 conforming HTML.
>
> But that's not my core point, which is that categorical statements
> such as you've offered are actually and notably injurious to the cause
> of promoting development in accessibility technology. You won't win
> new software development efforts by attacking the file-formats themselves.
>
> Look at it this way: Accessible alternatives to PDF files will depend
> in the real-world on re-use of PDF content because it is the only
> available content in many given situations. Lots of stuff is in PDF
> for reasons that just make sense to the players at hand in their
> respective business contexts, and that's the reality with which you need to engage.
>
> Having accepted it one ought (it seems to me) focus on highlighting
> the
> *lack* of technical barriers to full access to PDF, the degree of
> standardization available, the extent of implementation tools from
> PDFlib, iText, Adobe, Microsoft and others. Give developers reasons to
> invest in accessibility tools; do not foreclose on the potential for
> investment by proclaiming that somehow alternatives must be provided!
>
> When tagging or re-use fails a given user for a given reason, why, the
> PDF is the *critical* backup, tedious as it make be, it's still the
> *actual* document.
>
> That's the PDF focus and value-proposition, and it's got nothing to do
> with the ability to adjust kerning for X percent of users who need such.
> Equal access to the *same* content is - or ought to be - the focus here.
> There's no technical barrier to full accessibility (including TAdER
> parameters) to content delivered in PDF, and you do the community a
> disservice when you suggest otherwise.
>
> You would achieve far more, I think, by making statements similar to
> the
> following:
>
> "PDF files can only be considered fully accessible in every possible
> use-case when full TAdER text management is available."
>
> Only when you are using such constructive terms will you will then be
> helping, rather that hurting, the cause of improving access to content
> that exists (fact) in PDF.
>
> > Even well tagged PDF that is more accessible to screen reader users
> > is
> still *not accessible* to many people with other print disabilities.
> Accessibility is more than screen reader access.
>
> This is a straw-man. No-one claims this for PDF any more than for HTML.
>
> > Unfortunately, "tagged PDF" started getting called "accessible PDF"
> > --
> that is inaccurate and a harmful misnomer.
>
> Let's be completely clear on this.
>
> PDF that conforms with PDF/UA-1 (ISO 14289-1) is accessible, period.
> Whether it is accessibility-supported for any given need is *another
> matter* - a question for implementers, but assuredly not in question
> with respect to the file format.
>
> If vanilla HTML meets TAdER or TAdER-relevent standards for
> accessibility, then it's fair to say that PDF can qualify, because
> PDF/UA-1 conforming PDF files can be exported to the user's chosen
> HTML implementation. As you rightly point out, forms aren't yet
> supported in VIP Reader. Why is this more worthy of note that X, Y or
> Z failure of FaceBook, or iTunes or whatever to accommodate TAdER preferences?
>
> Do you really want to suggest that PDF is inaccessible now but can
> "become accessible" when (for example (VIP Reader adds the ability to print? C'mon.
>
> Now, anyone can and will concede that it's also possible to simply "tag"
> PDF without doing it well, just as its possible to do a half-ass job
> of ensuring CSS usage is accessible (for example). Tagging is a
> critical but insufficient part of meeting accessibility requirements for PDF content.
> Tell them that, instead of trying to make an (incorrect) grossly
> general claim about the file-format as a whole.
>
> > It perpetuates the lack of awareness, even among accessibility
> specialists, that PDF is actually not accessible to many people with
> print disabilities.
> >
> >> My job is to communicate one person's ideas to another person.
> >> I want to provide what is both legally required and what is
> >> desirable
> to the users.
> >
> > While PDF is a useful medium for some situations; when it is used,
> > there
> must be a more accessible alternative provided in order for the
> information to be available to people with disabilities.
>
> Once upon a time this was true. Today, this claim is inaccurate as
> written. It would be much more useful if it were re-written as follows
> (for
> example):
>
> "While PDF is a vital medium for many situations; when it is used, PDF
> creation, editing or reading software should create or read PDF/UA in
> order to generate or provide appropriate alternative representations
> of the PDF's content in order for that PDF's actual and inherent
> content to be available to the greatest possible number of people with disabilities."
>
> > I've been fairly quiet about this for many years (except to Adobe
> product managers :) because the accessibility of PDF has improved from
> years ago, but I'm deeply concerned about the *misconception that PDF
> is accessible*.
>
> PDF *can* be made accessible, and at this level of generalization,
> it's absurd to highlight PDF in format terms. Plenty of large-scale
> HTML implementations don't meet your preferred specifications for full
> accessibility today but I don't see you calling out HTML per se as
> "inaccessible."
>
> > For more info, please see:
> > * Text Customization for Readability <http://www.tader.info/>;
>
> I commend you for this site, and would unreservedly recommend that
> reader software implementers - regardless of medium - review your
> substantive recommendations for UI controls in readers.
>
> > * PDF viewers section of Support for Text Customization <
> http://www.tader.info/support.html#PDFisNOTaccessible>;
> >
> > (That is a work in progress and I welcome feedback directly.)
>
> Well, I've been no less public that you, I guess, with my opinion! ;)
>
> Duff.
> > > list messages to = EMAIL ADDRESS REMOVED =
>

From: Morin, Gary (NIH/OD) [E]
Date: Wed, Jul 10 2013 11:33AM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

Andrew - and with all due respect, while Accessibility of PDF may not be "largely focused on screen reader access for users who are blind", I do have to say that it is still largely focused on persons with vision impairments, even it if is across the range of vision impairment and not 'just' blind. Even in Chapter 21, Making Forms Accessible (http://acrobatusers.com/tutorials/making-forms-accessible), the following is stated:
* Accessible forms contain the structure and design that optimizes readability on screen reading devices for the vision and motion challenged users.
"Motion challenged" users - at least, those persons with dexterity impairments that I know and speaking for myself - do NOT use screen reading devices. We use speech recognition software. They're very different - and it's still very strongly ignored by the US's Section 508 "community" or "professionals" and, in general, by many if not most accessibility specialists. There's misinformation, lack of real understanding of the diversity of persons with disabilities and, all too often, a dismissing attitude when such issues are raised.
I applaud Adobe's addressing more than 'just' blind persons. And/but, like most of the accessibility and the IT professions, it's still pretty much vision-related only.
Speaking only for myself, not my employer, my worksite, or anyone else.
In peace and collegiality,
Gary
* Padova, Ted. Making forms accessible. February 1, 2013. http://acrobatusers.com/tutorials/making-forms-accessible
As a side note, "vision challenged" and "motion challenged" seem to be rather poor euphemisms for disability status.

From: Andrew Kirkpatrick
Date: Wed, Jul 10 2013 2:03PM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

Gary,
Just to be clear, the Acrobatusers.com site is a user community, so the document you are referring to is not an Adobe document. For the record, I agree that the word choice is not right also.

For users who depend on Speech recognition, this is an area where the speech recognition tools _could_ support interaction with Adobe Reader to red PDF documents in a more robust way, but haven't. Some speech recognition tool makers don't regard their tool as an accessibility tool but merely an efficiency tool, so they haven't bothered to utilize the accessibility API information that Reader provides for all assistive technologies, not just for screen readers or screen magnifiers. As a result, these tools do provide access to PDF documents but not with the full efficiency that is possible to help the end users.

I totally agree that speech recognition gets inadequate focus - if you have suggestions about how we can help promote improvements I'm happy to work toward greater access.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility

From: Morin, Gary (NIH/OD) [E] [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, July 10, 2013 1:33 PM
To: WebAIM Discussion List
Cc: Andrew Kirkpatrick
Subject: RE: [WebAIM] PDF on websites + PDF is *not* accessible

Andrew - and with all due respect, while Accessibility of PDF may not be "largely focused on screen reader access for users who are blind", I do have to say that it is still largely focused on persons with vision impairments, even it if is across the range of vision impairment and not 'just' blind. Even in Chapter 21, Making Forms Accessible (http://acrobatusers.com/tutorials/making-forms-accessible), the following is stated:
* Accessible forms contain the structure and design that optimizes readability on screen reading devices for the vision and motion challenged users.
"Motion challenged" users - at least, those persons with dexterity impairments that I know and speaking for myself - do NOT use screen reading devices. We use speech recognition software. They're very different - and it's still very strongly ignored by the US's Section 508 "community" or "professionals" and, in general, by many if not most accessibility specialists. There's misinformation, lack of real understanding of the diversity of persons with disabilities and, all too often, a dismissing attitude when such issues are raised.
I applaud Adobe's addressing more than 'just' blind persons. And/but, like most of the accessibility and the IT professions, it's still pretty much vision-related only.
Speaking only for myself, not my employer, my worksite, or anyone else.
In peace and collegiality,
Gary
* Padova, Ted. Making forms accessible. February 1, 2013. http://acrobatusers.com/tutorials/making-forms-accessible
As a side note, "vision challenged" and "motion challenged" seem to be rather poor euphemisms for disability status.

From: Duff Johnson
Date: Wed, Jul 10 2013 6:37PM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

> For users who depend on Speech recognition, this is an area where the speech recognition tools _could_ support interaction with Adobe Reader to red PDF documents in a more robust way, but haven't. Some speech recognition tool makers don't regard their tool as an accessibility tool but merely an efficiency tool, so they haven't bothered to utilize the accessibility API information that Reader provides for all assistive technologies, not just for screen readers or screen magnifiers. As a result, these tools do provide access to PDF documents but not with the full efficiency that is possible to help the end users.
>
> I totally agree that speech recognition gets inadequate focus - if you have suggestions about how we can help promote improvements I'm happy to work toward greater access.

I agree in general, but would emphasize a slightly different point.

a) To get your favorite software developer (of any type of AT, or other software they don't think of as AT) on-board with desirable levels of performance with PDF files, tell them you "want software that understands PDF/UA."

It's a very simple message and it tells them exactly how to start down the road, from a technical standpoint.

b) While accessibility requirements may often be expressed in screen-reader terms that's not because other UIs are being ignored per se. It is also true (and not a coincidence) that the features driving high-quality interactions using screen-readers is *also* the same feature-set (tags) that can be leveraged to help many different types of users (some of them not "disabled" at all) to to get around documents, tables, lists, links, etc, or get a good experience on mobile devices, or work with search engines, etc.

Here's the question:

If your software supports tagged PDF and (ideally) PDF/UA, it stands a very good chance indeed of delivering an excellent experience on a well-tagged PDF.

If your software doesn't support tagged PDF the chances aren't good at all, irrespective of the PDF.

Duff.

From: Ryan E. Benson
Date: Wed, Jul 10 2013 11:31PM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

> Acrobat - proprietary application from Adobe Systems
> PDF - open file-format

However, if you grab a copy of the PDF Standard, at least my copy, has the
following (c) Adobe Systems. So, if the format was truly open wouldn't ISO,
AIIM, PDF Association own it, not the proprietary company? Seems backwards
to me.

--
Ryan E. Benson


On Tue, Jul 9, 2013 at 6:47 PM, Duff Johnson < = EMAIL ADDRESS REMOVED = > wrote:

> On Jul 9, 2013, at 6:13 PM, "Ryan E. Benson" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Duff said:
> > First, this statement is equally true for plenty of implementations of
> HTML
> > / CSS / JavaScript technology, various combinations of which produce
> > results that defeat today's AT technologies. It's hardly a "PDF problem"
> -
> > calling out PDF specifically in this case is misleading.
> >
> > Duff this is incorrect. I can open up most browsers and define a user
> > stylesheet which allows me to do about anything I wish provided that I
> > understand CSS. Either by default, or via plugins, I can define a custom
> > stylesheet for a specific site. For example, in Firefox I have an outline
> > which makes it clear where the focus is. Of course there are ways
> > developers can get around my stylesheet.
>
> …and of course, there are ways in which PDF authors can get around making
> PDF files that can be effectively reused in the AT of choice as well!
>
> But my point is that while it's quite horrendously easy to achieve
> inaccessible PDF that is emphatically not the same as "PDF is inaccessible."
>
> > For example the Gmail UI likes to
> > use spans/divs instead of whatever a semantically appropriate tag would
> be.
> > In Acrobat, I can only choose from a few back/foreground colors.
>
>
> Acrobat - proprietary application from Adobe Systems
> PDF - open file-format
>
> There's a difference!
>
> My point is that a properly tagged PDF can - for these purposes - "become"
> an HTML file, and thus becomes susceptible to the sorts of enhancements you
> mention. pdfGoHTML demonstrates this fact, and it's free. Of course, it
> requires Acrobat, and doesn't (yet) work with Reader… but that's an
> implementation, not a file-format question.
>
> I'm simply trying to ensure we distinguish between PDF and applications
> which create or process PDF. The distinction is *vital* if one wishes to
> inform and affect software development.
>
> Duff.
> > > >

From: Olaf Drümmer
Date: Thu, Jul 11 2013 12:49AM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

Hi Ryan,

this goes back to a special arrangement between Adobe and ISO:
- usually you would have to purchase the PDF standard from ISO and pay for it
- as part of the handing over of the PDF spec to ISO, Adobe retained the right to offer as a free download the very same standard document
- in order to make clear which is which (offered by ISO for a fee vs. offered by Adobe free of charge), a copyright notice is included on the version of the PDF standard offered for download by Adobe
- that copyright notice is for **this specific** version of the standard (ISO most probably insisted on this for formal legal reasons)
- the copyright notice is not for the content / standard as such; this should also become very clear if you read the foreword and introduction.
- in case this hasn't become clear yet: PDF 1.7 as specified in ISO 32000-1 is wholly owned by ISO.

HTH

Olaf


On 11 Jul 2013, at 07:31, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:

>> Acrobat - proprietary application from Adobe Systems
>> PDF - open file-format
>
> However, if you grab a copy of the PDF Standard, at least my copy, has the
> following (c) Adobe Systems. So, if the format was truly open wouldn't ISO,
> AIIM, PDF Association own it, not the proprietary company? Seems backwards
> to me.
>
> --
> Ryan E. Benson
>

From: Andrew Kirkpatrick
Date: Thu, Jul 11 2013 7:10AM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

What Olaf said saves me some typing.

For reference, this is the Adobe-hosted copy: http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf, which we provide on this page http://www.adobe.com/devnet/pdf/pdf_reference.html

We do provide the text on that page that reads: "This document is an ISO approved copy of the ISO 32000-1 Standards document. By agreement with ISO, Adobe Systems Incorporated is allowed to offer this version of the ISO standard as a free PDF file on their own Web site. It is not an official ISO document but the technical content is identical; the page and section numbers are also preserved."

If you'd like to buy it, you can do so here: http://www.iso.org/iso/catalogue_detail.htm?csnumber=51502

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility


From: Shawn Henry (uiAccess projects)
Date: Fri, Jul 12 2013 4:02AM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | Next message →

(Olaf and I had a very congenial, constructive exchange off-list, which informed some of my comments below.)

First and foremost, I whole-heartedly agree that my text did not accurately distinguish between PDF files and the "PDF format", and this is an important distinction. I have edited the information on http://www.tader.info to reflect this distinction. I will be more careful of this.

To clarify here: I am stating only that PDF files are not accessible today because of the lack of text customization functionality in PDF Reader and other viewers. I do not mean to make any statement about the "PDF format itself". (I do not know enough about the technical aspects of the format -- although I do wonder if there may be fundamental issues with the format given the limitations of all viewers, for example, not to reflow PDF files with forms.)

My goal is to encourage Adobe Reader, other PDF viewers, and "user agents" for other technologies/formats (including web browsers for HTML) to provide sufficient text customization functionality that is easy for people to use. I do not want to banish PDF altogether. The reason I am emphasizing that PDF files are not currently accessible is that it is not well understood, even among PDF experts and accessibility specialists. My purpose is to educate accessibility advocates and content providers on the current limitations of PDF viewers in order to motivate them to actively encourage improvements in Adobe Reader. (Yes, there are other viewers, but ideally the mainstream one supports accessibility.) If people do not understand there is a problem, they won't know to encourage it to be fixed.

I sincerely apologize that my comments came across to some as not respecting the work to improve PDF accessibility, especially for screen reader users. I do appreciate and acknowledge all that work! In fact, that is why I have been quiet about this issue for so long. I've been bugging Adobe accessibility manager Andrew Kirkpatrick, and before him Bob Regan, about it for several years. I said almost nothing publicly until last year because they were making improvements in accessibility.

The issue now is that people are not speaking up enough about users' needs to customize text display. People with low vision, dyslexia, and related conditions that impact reading are a large user group –larger than people who are blind-, we just don't have coordinated advocacy. I don't know specific statistics on how many people need to customize text, however, these stats provide some insight: An estimated 15–20% of the population has symptoms of dyslexia, and 246 million have low vision (compared to 39 million who are blind) [references at <http://www.tader.info/understanding.html#refstats>;] -- and these numbers are increasing due to age-related impairments. Text customization is not just nice-to-have for a few; it is a requirement for a significant number of people. Please see <http://www.tader.info/baddisplay.html>; for enlightening comments and survey data.

I have another request, particularly to those ingrained in PDF: Would you consider thinking differently about "documents" and instead think of access to information?
I agree that PDF is the best format in many cases *for printing specifically-designed information*. However, when you want to provide information that is accessible to most people, perhaps it needs to be offered in another format...


Replies on specific points are below, preceded with "SLH".

On 7/9/2013 10:51 AM, Duff Johnson wrote:
...
>> The problem is that PDF is currently *not sufficiently accessible*
>> to many people with low vision, dyslexia, and related conditions
>> and situations that impact reading - because Adobe Reader and other
>> PDF viewers lack sufficient text customization functionality.
>
> First, this statement is equally true for plenty of implementations
> of HTML / CSS / JavaScript technology, various combinations of which
> produce results that defeat today's AT technologies. It's hardly a
> "PDF problem" - calling out PDF specifically in this case is
> misleading.

SLH: Sorry I wasn't clear. I mean that even well-tagged PDF files designed well for accessibility are currently not sufficiently accessible to many people with low vision, dyslexia, and related conditions that impact reading - because Adobe Reader and other PDF viewers lack sufficient text customization functionality.

...

> You would achieve far more, I think, by making statements similar to
> the following:
>
> "PDF files can only be considered fully accessible in every possible
> use-case when full TAdER text management is available."

SLH: Point taken -- however, I would not say that any files (PDF or HTML or Word processing files) can be "fully accessible in every possible use-case" (note WCAG's disclaimer: "...even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees,..."). I agree that:
PDF files can only be considered accessible to some people with low vision, dyslexia, and related conditions that impact reading when the PDF viewer they use provides sufficient text customization. (but currently none are available)

...

>> Unfortunately, "tagged PDF" started getting called "accessible PDF"
>> -- that is inaccurate and a harmful misnomer.
>
> Let's be completely clear on this.
>
> PDF that conforms with PDF/UA-1 (ISO 14289-1) is accessible, period.
> Whether it is accessibility-supported for any given need is *another
> matter* - a question for implementers, but assuredly not in question
> with respect to the file format.

SLH: Right, I need to distinguish between files and format. Not talking about the format, but about the real world user situation today: *Even PDF files that conform with PDF/UA-1 (ISO 14289-1) are not currently accessible* to some people with low vision, dyslexia, and related conditions that impact reading - because PDF viewers lack sufficient text customization functionality.

...

> Do you really want to suggest that PDF is inaccessible now but can
> "become accessible" when (for example (VIP Reader adds the ability to
> print? ...

SLH: Yes, exactly! – with the clarification of files, not format: PDF files are inaccessible now, but can become accessible to most people when PDF viewers provide sufficient text customization.
(which is more than the ability to print <http://www.tader.info/display.html>;)

(side note: I updated the information on VIP PDF-Reader to be more specific about which aspects of text customization it supports and which it does not yet -- and to praise their work and openness to improvements. <http://www.tader.info/support.html#vipreader>;)
(tangent: VIP PDF-Reader provides excellent line, word, and character spacing settings – you can set them to any point, instead of just selecting from a limited number of pre-defined points. My problem is that I haven't figured out how to say that succinctly in <http://www.tader.info/support.html#vipreader>;. If you have suggestions for a term to express it, I'd really appreciate the help. :)

...

---

SLH: It seems that my lack of distinction between files and format was the source of disagreements. I'm sorry! I'm optimistic that with these clarifications we're now more aligned to work together on making information more accessible to all!

Sincerely,
~Shawn



<http://www.uiaccess.com/profile.html>;
Note: Please be careful in referencing the information on the tader.info website and e-mails from uiAccess.com as from the individual Shawn, not her employer.

From: Duff Johnson
Date: Fri, Jul 12 2013 1:01PM
Subject: Re: PDF on websites + PDF is *not* accessible
← Previous message | No next message

On Jul 12, 2013, at 6:02 AM, "Shawn Henry (uiAccess projects)" < = EMAIL ADDRESS REMOVED = > wrote:

> (Olaf and I had a very congenial, constructive exchange off-list

Olaf is not (only) a bear. ;-)

> First and foremost, I whole-heartedly agree that my text did not accurately distinguish between PDF files and the "PDF format", and this is an important distinction. I have edited the information on http://www.tader.info to reflect this distinction. I will be more careful of this.

Much appreciated!

Some of us in PDF-land are working towards the day when Shawn will say: "No matter what other format you use, you also have to deliver well-tagged PDF in order to ensure your document is accessible to the greatest number of users."

:)

> To clarify here: I am stating only that PDF files are not accessible today because of the lack of text customization functionality in PDF Reader and other viewers. I do not mean to make any statement about the "PDF format itself". (I do not know enough about the technical aspects of the format -- although I do wonder if there may be fundamental issues with the format given the limitations of all viewers, for example, not to reflow PDF files with forms.)

Form fields - in fact, any interactive content - presents additional challenges for tagged-PDF-to-HTML conversion and display engines, which is what we're talking about here. But there are no fundamental reasons why form-fields can't be included in tags-based reflow.

Tell SZB you want to see support for forms in the next release of VIP Reader; tell Adobe you want to see it in the next-generation reflow tool from Adobe for Acrobat/Reader. You know the drill!

> My goal is to encourage Adobe Reader, other PDF viewers, and "user agents" for other technologies/formats (including web browsers for HTML) to provide sufficient text customization functionality that is easy for people to use.

I know it is! Which is why we're having this fun and very public conversation. :)

Adobe doesn't want to hear from *me* again - they already know what I think.

My goal is to maximize accessibility advocates' effectiveness in advocating for their goals with software developers.

> I do not want to banish PDF altogether.

That's good, because it's not within anyone's power to do so.

Allow me to quote, if I may, from the introduction to the forthcoming Matterhorn Protocol:

"PDF is the electronic document format found worldwide in every corner of almost every organization that uses computers. The value of PDF may be stated in terms of the capacity to deliver a stable and trustworthy representation of a document."

> The reason I am emphasizing that PDF files are not currently accessible is that it is not well understood, even among PDF experts and accessibility specialists. My purpose is to educate accessibility advocates and content providers on the current limitations of PDF viewers in order to motivate them to actively encourage improvements in Adobe Reader. (Yes, there are other viewers, but ideally the mainstream one supports accessibility.) If people do not understand there is a problem, they won't know to encourage it to be fixed.

It used to be in the accessibility world that *everyone* hated PDF and Adobe Reader; that almost no-one believed PDF files could be accessible! Are you telling me that this situation has flipped; that people now don't believe there's a problem?

Nah…

> I sincerely apologize that my comments came across to some as not respecting the work to improve PDF accessibility, especially for screen reader users. I do appreciate and acknowledge all that work!

I know you do.

> In fact, that is why I have been quiet about this issue for so long. I've been bugging Adobe accessibility manager Andrew Kirkpatrick, and before him Bob Regan, about it for several years. I said almost nothing publicly until last year because they were making improvements in accessibility.

"Quiet" doesn't influence product development. NOISY does! And more than being individually noisy, getting others to be noisy is much better, and getting big customers to be noisy is the very *best* way.

Product managers are just like everyone else: they fight the fire that's burning highest. You want something? Throw gas on the fire.

Now… Adobe's not been that great at blowing their own horn on this, perhaps because they are afraid of raising expectations. However, it's important to praise their efforts and progress even while demanding more more more.

Adobe has invested heavily in tagged PDF development… inventing it in the first place, producing a first and second generation of tools and *crucially* leading the way with an API that allows AT to get to the tags in the first place.

I know many fine people at Adobe who really care about this issue and work hard to promote accessibility in the company's development priorities. But they need help, and that means vocal support from the community for accessible PDF tools… and a lot less of the broad-brush condemnations of PDF as a format, technology, whatever.

> The issue now is that people are not speaking up enough about users' needs to customize text display. People with low vision, dyslexia, and related conditions that impact reading are a large user group –larger than people who are blind-, we just don't have coordinated advocacy.

I'd say they've got a potent advocate in you!

> I don't know specific statistics on how many people need to customize text, however, these stats provide some insight: An estimated 15–20% of the population has symptoms of dyslexia, and 246 million have low vision (compared to 39 million who are blind) [references at <http://www.tader.info/understanding.html#refstats>;] -- and these numbers are increasing due to age-related impairments. Text customization is not just nice-to-have for a few; it is a requirement for a significant number of people. Please see <http://www.tader.info/baddisplay.html>; for enlightening comments and survey data.

This is why I am *so* enthusiastic about VIP Reader! I encourage anyone to download it, try it, and then, contribute to its future development. Full TAdER support really isn't that far off…

> I have another request, particularly to those ingrained in PDF: Would you consider thinking differently about "documents" and instead think of access to information?
> I agree that PDF is the best format in many cases *for printing specifically-designed information*. However, when you want to provide information that is accessible to most people, perhaps it needs to be offered in another format…

While I take your point I want to ask you to turn the point around.

PDF is not about "printing". It's about the ability to share (exchange) graphically rich information in a completely reliable way, regardless of platform. See the introduction to Matterhorn, quoted above.

There are "documents" - they exist; they are unavoidable.

From tax forms to ordinances to gas bills to advertisements to product packaging to contracts, graphically-rich content that's "frozen" at a specific moment becomes a "document" - an irreducible aspect of communications.

The *real* question is: will you insist that documents be accessible and supported with adequate reading technology, or that somehow "document-ness" has to be avoided?

I vote for insisting documents be accessible. ;)

> Replies on specific points are below, preceded with "SLH".

I have a few more comments preceded by "DJ" but I've otherwise snipped for brevity's sake.

> SLH: Right, I need to distinguish between files and format. Not talking about the format, but about the real world user situation today: *Even PDF files that conform with PDF/UA-1 (ISO 14289-1) are not currently accessible* to some people with low vision, dyslexia, and related conditions that impact reading - because PDF viewers lack sufficient text customization functionality.

DJ: Yes!! Now we're got the wood behind the right arrow!

>> Do you really want to suggest that PDF is inaccessible now but can
>> "become accessible" when (for example (VIP Reader adds the ability to
>> print? ...
>
> SLH: Yes, exactly! – with the clarification of files, not format: PDF files are inaccessible now, but can become accessible to most people when PDF viewers provide sufficient text customization.
> (which is more than the ability to print <http://www.tader.info/display.html>;)

DJ: We are on the same page. I am delighted to recommend TAdER as *required reading* for software developers interested in accessibility, and I'll promote it as such in my presentation at next month's Technical Conference in Seattle.

SHAMELESS PLUG: Interested in PDF accessibility from a technical standpoint? This August 14-15 in Seattle it's the PDF Association Technical Conference!! More info:

http://www.pdfa.org/event/technical-conference-north-america-2013/

> (side note: I updated the information on VIP PDF-Reader to be more specific about which aspects of text customization it supports and which it does not yet -- and to praise their work and openness to improvements. <http://www.tader.info/support.html#vipreader>;)

DJ: Please also consider encouraging support for development of VIP Reader via donation to SZB, the Swiss non-profit which commissioned the software's development.

> (tangent: VIP PDF-Reader provides excellent line, word, and character spacing settings – you can set them to any point, instead of just selecting from a limited number of pre-defined points. My problem is that I haven't figured out how to say that succinctly in <http://www.tader.info/support.html#vipreader>;. If you have suggestions for a term to express it, I'd really appreciate the help. :)

DJ: Interesting question, I will ponder it.

Perhaps...

…"full flexibility in representing text, including… <a list>"

> SLH: It seems that my lack of distinction between files and format was the source of disagreements. I'm sorry! I'm optimistic that with these clarifications we're now more aligned to work together on making information more accessible to all!

DJ: We are! Thank you for being so open to the discussion!

Duff.