W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2016

Re: PDF accessibility and complex script languages.

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Mon, 4 Jan 2016 13:17:55 -0800
Message-ID: <CAHu5OWYa7oax348k-1-SSa_V3xrxPQ7-FCWe0KOjwm5kQoNgKw@mail.gmail.com>
To: Andrew Cunningham <andj.cunningham@gmail.com>
Cc: Duff Johnson <duff@duff-johnson.com>, WAI Interest Group <w3c-wai-ig@w3.org>
For the accessibility API, ActualText will replace whatever it is an
attribute for, including glyph/test content.

However, I do not know whether search or cut/paste support the use of
ActualText, and I would not be surprised to learn that they do not. If they
do not, you should definitely file a bug.

On Mon, Jan 4, 2016 at 1:10 PM, Andrew Cunningham <andj.cunningham@gmail.com
> wrote:

>
> On 5 Jan 2016 7:25 am, "Duff Johnson" <duff@duff-johnson.com> wrote:
> >
>
> >
> > It’s typical for PDF consuming tools that extract or process text to use
> ActualText. Software that cannot process ActualText cannot be claimed to
> support accessible (i.e., tagged) PDF.
> >
> >
>
> I need to do more testing i suspect.
>
> Image with ActualText seems to work fine.
>
> Text AND ActualText combination seems to need more testing.  I need to do
> more testing of text extraction and searching. Even something as simple as
> cutting and pasting from a PDF seems to be problematic.
>
> When I have cut and pasted from a test PDF for instance the operation
> seems to occur at the glyph/text level, and not the ActualText.
>
> I guess i need to try alternative software. And map out what would work
> best for each language.
>
> Andrew
>
Received on Monday, 4 January 2016 21:18:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 January 2016 16:39:04 UTC