Pdf.js: Включить поддержку PDF-файлов с тегами

Добавлен ярлык [требуется сортировка]. Нужен ли нам новый ярлык (4-tagged-pdf) для разработки, связанной с документами PDF с тегами?

У нас есть примеры PDF-файлов? Я лично таких PDF-файлов не видел. Как часто они используются на практике?

Да, у нас есть пара таких:

$ cd test/pdfs/
$ grep -rla '/Marked true'
i9.pdf
fips197.pdf
issue1169.pdf
smaskdim.pdf
issue3879.pdf
bug816075.pdf
pdf.pdf
issue1709.pdf
f1040.pdf
wdsg_fitc.pdf
annotation-border-styles.pdf
ecma262.pdf
bug887152.pdf
issue1133.pdf
issue2442.pdf
issue1796.pdf
type4psfunc.pdf

Если вам нужно больше, https://encrypted.google.com/search?q=filetype%3Apdf+ "% 2FMarkInfo" + "% 2FMarked + true"

Спасибо! В таком случае, определенно интересно в это разобраться.

Я думаю, что было бы относительно легко реализовать это, используя сочетание атрибутов HTML и ARIA - никаких изменений в рендеринге не требуется - просто добавьте несколько новых атрибутов.

Информация о тегах PDF хранится в дереве StructTreeRoot, которое содержит элементы структуры с информацией о доступности, такой как альтернативный текст, язык и семантический тип (H1, TH, LI и т. Д.). Элементы структуры содержат ссылки на объекты в потоке содержимого страницы. Вот график, показывающий это:
https://stackoverflow.com/a/34047585

Я думаю, вы можете вставить информацию о тегах PDF в _layoutText(textDiv) используя что-то вроде этого:

1) Найдите соответствующий элемент структуры в дереве StructTreeRoot для визуализируемого объекта PDF.
2) Добавьте атрибут role в div, если элемент структуры имеет тип структуры, такой как H1, H2, LI и т. Д.
3) Добавьте атрибут aria-label в div, если элемент структуры имеет запись / Alt
4) Добавьте атрибут aria-level в div, соответствующий уровню заголовка для типов структуры H1-H6.

Это должно сделать заголовки, списки и изображения доступными для программы чтения с экрана. Таблицы могут быть более сложными для реализации.

Типы структур PDF перечислены в разделе 14.8.4.3. из
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Для заголовка рендеринг изменится с этого:

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);">
7.  Evaluation
</span>

к этому:

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);" 
role="heading" aria-level="1">
7.  Evaluation
</span>

Затем программа чтения с экрана будет читать это как «7. Оценка, уровень заголовка 1» и, что более важно, позволяет пользователю переходить между заголовками с помощью клавиши «следующий заголовок» (что значительно упрощает навигацию по большим документам).

Я заметил, что метка 4-tagged-pdf была удалена. Это все еще то, чего добиваются?

Открытость вопроса означает, что мы его рассматриваем. Это особенность, и надписи немного переупорядочены.

Ух ты, здорово! Включает ли эта рассматриваемая функция поддержку создания файлов PDF с тегами? Это могло бы облегчить реализацию чего-то вроде парсера / анализатора для существующих PDF-файлов, но также обеспечило бы поддержку для создания PDF-файлов 508c.

Основные функции, необходимые для создания PDF-файлов 508c:

• пометить документ (языком и заголовком, возможно, другими тегами)
• пометьте структурные объекты внутри PDF (заголовок, таблица, th, td, списки и т. д.)
• добавлять альтернативный текст к визуальным медиа (изображениям, видео, рисункам и т. д.)
• создавать / поддерживать порядок табуляции элементов

Если бы для этих 4 вещей существовала основная функциональность, то можно было бы реализовать логику в процессе генерации PDF, которая создала бы PDF-файлы 508c. Что, честно говоря, было бы огромным, поскольку я еще не нашел ни одного инструмента JavaScript с открытым исходным кодом, поддерживающего эту функцию.

Написав это, я не уверен, будет ли это квалифицироваться как отдельный запрос функции или нет ... Я с радостью создам новую проблему, если это так.

Я работал с @cuhaller, чтобы обеспечить лучшее соответствие SC 2.4.10 и 1.1.1 WCAG 2.0 для случаев использования, специфичных для приложения, над которым работает его команда.

Я считаю, что изменений должно быть достаточно для выполнения части того, что требует эта проблема. У меня будет PR на следующей неделе или около того, следуя руководящим принципам . Я обновлю эту тему, когда отправлю.

У меня есть изменения в форке PDF.js 2.3.200, чтобы обеспечить уровни заголовков и альтернативный текст изображения (без позиционирования), расположенный в ветке headings -and-img-alt-text этого репо .

Я не решаюсь открывать PR, поскольку существуют конфликты слияния против мастера, и в настоящее время у меня нет времени на их разрешение.

Если у кого-то есть возможность обновить эту ветку с помощью мастера, давайте свяжемся с вами!

Edge рекламировал встроенную поддержку файлов PDF с тегами. Chrome также теперь поддерживает его, а также рекламирует свою возможность экспортировать файлы PDF с тегами с веб-страниц.

Сегодня Firefox не предоставляет теги в PDF-файлах для дерева доступности / API специальных возможностей. Однако этот текст находится в списке функций Firefox 80 :

Теперь Firefox можно установить как системную программу просмотра PDF-файлов по умолчанию.

Если это делает пользователь, который полагается на AT, или системный администратор, который не знает состав пользователей, может быть проблематичным для тех пользователей, которые в противном случае полагались на Edge, Chrome или Adobe Reader, чтобы проанализировать для них PDF-файлы с тегами. .

Я настоятельно рекомендую исключить совет из примечаний к выпуску для 80 и повысить приоритет этой ошибки. Я понимаю, что ресурсы Mozilla сейчас ограничены, но оптика по продвижению недоступной функции, которая лучше обслуживается в конкурирующих браузерах, выглядит не очень хорошо.

Наша организация стремится внедрить доступное решение PDF для пользователей вспомогательных технологий. Мы пришли к выводу, что предварительный просмотр PDF-файла с помощью PDF JS недоступен, поскольку отсутствует семантическая разметка. Отсутствие семантической информации создает препятствия для пользователей, которые взаимодействуют с программным обеспечением для чтения с экрана. Хотя PDF-файл отображается в виде обычного текста и объявляет аннотации, разметка не предоставляется для заголовков, таблиц, изображений или ссылок.

Сценарии использования таблиц особенно трудны для пользователей программ чтения с экрана. Таблицы без семантической разметки не предоставляют пользователям контекста и не могут полностью понять информацию, представленную в PDF-файле, для пользователей программ чтения с экрана.

Ссылки объявляются как URL-адреса, а не как конкретный текст ссылки, что затрудняет понимание цели ссылки. Мы рекомендуем использовать видимый текст ссылки вместо URL-адреса ссылки, чтобы пользователи понимали ссылку в контексте.

Без этой поддержки у нас есть опасения по поводу широкой реализации PDF JS. Есть ли какие-либо обновления или временные рамки для поддержки функции для обеспечения семантической разметки? Мы просим считать этот вопрос более приоритетным, поскольку он влияет на способность пользователей воспринимать контент и взаимодействовать с ним.

Насколько я знаю, взносы более чем приветствуются.

Спасибо @trjohnst за вашу работу над этим.

Я начал вручную перебазировать ветку @trjohnst на мастере pdf.js. Этот подход хорошо работает для тегов, которым нужен только один уровень; например, заголовки или изображения с замещающим текстом. При просмотре потока контента, если он встречает последовательность помеченного контента, он ищет связанный элемент структуры и помещает соответствующую роль ARIA в текстовый диапазон в выводе HTML текстовым слоем pdf.js.

К сожалению, этого недостаточно для всего, что требует вложенных тегов; например, списки или таблицы. Я не думаю, что этот подход можно расширить, чтобы охватить их, по крайней мере, без множества сложных крайних случаев. Кроме того, чтобы правильно поддерживать ссылки и поля формы (и обратите внимание, что поля формы не поддерживались pdf.js во время вклада @trjohnst ), нам нужно иметь возможность учитывать уровень аннотаций, а не только текстовый слой. Если подумать еще дальше, было бы хорошо иметь возможность реализовать эвристику, чтобы попытаться обнаруживать (и правильно позиционировать) заголовки, ссылки, таблицы, поля форм и т. Д. В немаркированных PDF-файлах.

Вместо того, чтобы пытаться сделать это в текстовом слое, я думаю, нам нужно будет пройтись по дереву структуры и отрендерить узлы на основе этого, установив свойства ARIA для элементов, которые мы выводим. Дерево структуры может ссылаться на данные как в текстовом, так и в аннотационном слое. Мы можем либо переупорядочить узлы DOM слоя текста и аннотаций на основе дерева структуры (может быть сложно без нарушения визуального рендеринга?), Либо использовать aria-owns, чтобы переупорядочить только дерево a11y без изменения порядка DOM.

С архитектурной точки зрения это сложно, потому что слои текста и аннотаций уже отображаются отдельно, и теперь нам нужно взглянуть на третий слой (или, по крайней мере, на источник истины), дерево структуры, которое может перемещать (или ссылаться) на узлы в обоих из них. другие слои. Самый простой способ сделать это, вероятно, - привязать идентификатор к каждой последовательности помеченного содержимого (в текстовом слое) и поле ссылки / формы (в слое аннотации). Я вижу, что в полях формы уже есть атрибут данных, указывающий идентификатор. Если мы собираемся использовать aria-owns, нам все равно нужно установить атрибут id, чтобы можно было накормить двух птиц одной лепешкой. Идентификатор должен быть чем-то, что мы можем вычислить вне слоев текста и аннотаций, изнутри нашего нового слоя структуры. Когда мы обрабатываем дерево структуры, мы затем выводим элементы для элементов структуры, перемещая / владея элементами из слоев текста / аннотаций на основе их идентификаторов.

Выходя за рамки тегированного PDF-файла и заканчивая эвристикой, мы должны иметь возможность делать такие вещи, как: учитывая ссылку или аннотацию поля формы, охватывает ли его прямоугольник что-то в текстовом слое? если это так, аннотация должна быть связана с ее текстом (aria-own или DOM move). Опять же, это сложно с архитектурной точки зрения, потому что слои текста и аннотаций (и их входные данные) разделены, и я не думаю, что у нас есть какое-либо кешированное состояние из этих слоев, которые мы можем использовать. Тем не менее, мы потенциально можем смотреть на границы узлов, отображаемых слоями текста и аннотаций, хотя это начинает стирать архитектурные границы между обработкой контента и представления.

Хотя первоначальная реализация PDF с тегами не обязательно должна поддерживать эвристику, я настоятельно рекомендую рассматривать это как часть архитектурного проекта. Реальность такова, что немаркированные PDF-файлы, к сожалению, очень распространены, и было бы грустно быть привязанным к архитектуре, которая не позволяет сделать их более доступными. (Обратите внимание, что Acrobat Reader и, в гораздо меньшей степени, Chromium, используют эвристику, чтобы попытаться сделать немаркированные PDF-файлы более доступными.)