Pdf.js: Sertakan dukungan untuk PDF yang ditandai

Menambahkan label [diperlukan triase]. Apakah kami memerlukan label baru (4-tagged-pdf) untuk pengembangan terkait dengan PDF yang diberi tag?

Apakah kami memiliki contoh PDF? Saya pribadi belum pernah melihat PDF seperti itu. Seberapa sering mereka digunakan dalam praktik?

Ya, kami memiliki beberapa di antaranya:

$ 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

Jika Anda membutuhkan lebih banyak, https://encrypted.google.com/search?q=filetype%3Apdf+ "%2FMarkInfo"+"%2FMarked+true"

Terima kasih! Dalam hal ini, pasti menarik untuk melihat ini.

Saya pikir mungkin relatif mudah untuk menerapkan ini menggunakan campuran atribut HTML dan ARIA - tidak ada perubahan pada rendering yang diperlukan - cukup tambahkan beberapa atribut baru.

Info penandaan PDF disimpan di pohon StructTreeRoot, yang berisi elemen struktur dengan info aksesibilitas seperti teks alternatif, bahasa, dan tipe semantik (H1, TH, LI, dll). Elemen struktur berisi referensi ke objek dalam aliran konten halaman. Ada grafik yang menunjukkan ini di sini:
https://stackoverflow.com/a/34047585

Saya pikir Anda dapat menyuntikkan info penandaan PDF di _layoutText(textDiv) menggunakan sesuatu seperti ini:

1) Cari elemen struktur yang sesuai di pohon StructTreeRoot untuk objek PDF yang sedang dirender
2) Tambahkan atribut role ke div jika elemen struktur memiliki tipe struktur seperti H1, H2, LI dll.
3) Tambahkan atribut aria-label ke div jika elemen struktur memiliki entri /Alt
4) Tambahkan atribut aria-level ke div yang sesuai dengan level heading untuk tipe struktur H1-H6

Ini akan membuat judul, daftar, dan gambar dapat diakses oleh pembaca layar. Tabel mungkin lebih rumit untuk diterapkan.

Jenis struktur PDF tercantum di bagian 14.8.4.3. dari
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Untuk heading, rendering akan berubah dari ini:

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

untuk ini:

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

Itu kemudian akan dibaca oleh pembaca layar sebagai "7. Evaluasi, heading level 1" dan yang lebih penting memungkinkan pengguna melewati antar heading menggunakan tombol 'heading berikutnya' (yang membuat dokumen besar lebih mudah dinavigasi)

Saya perhatikan label 4-tagged-pdf telah dihapus. Apakah ini masih sesuatu yang dikejar?

Masalah yang terbuka menunjukkan bahwa kami sedang mempertimbangkannya. Ini adalah fitur, dan label telah diatur ulang sedikit.

Wah, bagus sekali! Apakah fitur yang sedang dipertimbangkan ini mencakup dukungan untuk menghasilkan PDF yang diberi tag? Ini dapat memfasilitasi penerapan sesuatu seperti pengurai/penganalisis untuk PDF yang ada, tetapi juga akan memberikan dukungan untuk menghasilkan PDF 508c.

Fungsionalitas Inti Diperlukan untuk Menghasilkan 508c PDF:

• tag dokumen (dengan bahasa dan judul, mungkin tag lain)
• menandai objek struktural di dalam PDF (tajuk, tabel, th, td, daftar, dll.)
• menambahkan teks alternatif ke media visual (gambar, video, gambar, dll.)
• buat/pertahankan urutan tab elemen

Jika fungsionalitas inti ada untuk 4 hal ini, maka dimungkinkan untuk menerapkan logika dalam proses pembuatan PDF yang akan menghasilkan PDF 508c. Yang, sejujurnya, akan sangat besar, karena saya belum menemukan alat javascript OpenSource dengan fungsi ini didukung.

Setelah menulis ini, saya tidak yakin apakah ini akan memenuhi syarat sebagai permintaan fitur terpisah atau tidak... Saya akan dengan senang hati membuat masalah baru jika itu masalahnya.

Saya telah bekerja dengan @cuhaller untuk memberikan kepatuhan yang lebih baik dengan SC 2.4.10 dan 1.1.1 dari WCAG 2.0 untuk kasus penggunaan khusus untuk aplikasi yang sedang dikerjakan timnya.

Saya percaya perubahan harus cukup untuk sebagian dari apa yang perlu dilakukan oleh masalah ini. Saya akan memiliki PR dalam minggu depan atau lebih mengikuti pedoman kontribusi . Saya akan memperbarui utas ini ketika saya mengirim.

Saya memiliki perubahan dalam garpu dari 2.3.200 PDF.js untuk memberikan tingkat judul dan teks gambar alternatif (tanpa pemosisian) yang terletak di cabang headings-and-img-alt-text dari repo ini .

Saya ragu untuk membuka PR karena ada konflik gabungan melawan master dan saat ini saya tidak punya waktu untuk menyelesaikannya.

Jika ada yang memiliki ketersediaan untuk memperbarui cabang ini dengan master, mari kita hubungi!

Edge telah menggembar-gemborkan dukungan asli untuk PDF yang ditandai. Chrome juga sekarang mendukungnya, dan juga memuji kemampuannya yang akan datang untuk mengekspor PDF yang diberi tag dari halaman web.

Saat ini, Firefox tidak mengekspos penandaan dalam PDF ke pohon aksesibilitas/API aksesibilitas. Namun, teks ini ada di daftar fitur untuk Firefox 80 :

Firefox sekarang dapat disetel sebagai penampil PDF sistem default.

Jika pengguna yang mengandalkan AT melakukan ini, atau administrator sistem yang tidak mengetahui susunan pengguna melakukan ini, dapat menjadi masalah bagi pengguna yang mengandalkan Edge, Chrome, atau Adobe's Reader untuk mengurai PDF yang diberi tag untuk mereka. .

Saya sangat menyarankan agar saran dihapus dari catatan rilis untuk 80, dan prioritas bug ini ditingkatkan. Saya mengerti Mozilla adalah sumber daya yang terbatas sekarang, tetapi cara untuk mempromosikan fitur yang tidak dapat diakses yang lebih baik disajikan di browser yang bersaing bukanlah tampilan yang bagus.

Organisasi kami ingin menerapkan solusi PDF yang dapat diakses untuk pengguna teknologi bantu. Kami sampai pada kesimpulan bahwa mempratinjau PDF dengan PDF JS tidak dapat diakses karena markup semantik tidak ada. Kurangnya informasi semantik menciptakan hambatan bagi pengguna yang berinteraksi dengan perangkat lunak pembaca layar. Sementara PDF tidak ditampilkan dalam teks biasa dan mengumumkan anotasi, markup tidak disediakan untuk judul, tabel, gambar, atau tautan.

Kasus penggunaan di sekitar tabel sangat sulit bagi pengguna pembaca layar. Tabel yang tidak memiliki markup semantik tidak memberikan konteks kepada pengguna dan tidak mungkin bagi pengguna pembaca layar untuk memahami sepenuhnya informasi yang disajikan dalam PDF.

Tautan diumumkan sebagai URL alih-alih teks tautan tertentu yang membuat pemahaman tujuan tautan menjadi sulit. Kami akan merekomendasikan agar tautan menggunakan teks tautan yang terlihat alih-alih URL tautan, sehingga pengguna akan memahami tautan dalam konteksnya.

Tanpa dukungan ini, kami memiliki kekhawatiran tentang penerapan PDF JS secara luas. Apakah ada pembaruan atau garis waktu seputar dukungan fitur untuk menyediakan markup semantik? Kami meminta agar masalah ini dianggap sebagai prioritas yang lebih tinggi karena berdampak pada kemampuan pengguna untuk memahami dan berinteraksi dengan konten.

Sejauh yang saya tahu, kontribusi lebih dari diterima

Terima kasih @trjohnst atas pekerjaan Anda dalam hal ini.

Saya mulai secara manual me- rebasing cabang @trjohnst di pdf.js master. Pendekatan ini bekerja dengan baik untuk tag yang hanya membutuhkan satu level; misalnya judul atau gambar dengan teks alternatif. Saat berjalan di aliran konten, jika menemukan urutan konten yang ditandai, ia mencari elemen struktur terkait dan menempatkan peran ARIA yang sesuai pada rentang teks dalam output HTML oleh lapisan teks pdf.js.

Sayangnya, ini tidak cukup untuk apa pun yang membutuhkan tag bersarang; misalnya daftar atau tabel. Saya tidak berpikir pendekatannya dapat diperluas untuk mencakup itu, setidaknya bukan tanpa banyak kasus Edge yang rumit. Selanjutnya, untuk mendukung tautan dan bidang formulir dengan benar (dan perhatikan bahwa bidang formulir tidak didukung oleh pdf.js pada saat kontribusi @trjohnst ), kita harus dapat mempertimbangkan lapisan anotasi, bukan hanya lapisan teks. Berpikir lebih jauh ke depan, akan lebih baik untuk dapat menerapkan heuristik untuk mencoba mendeteksi (dan memposisikan dengan benar) judul, tautan, tabel, bidang formulir, dll. dalam PDF yang tidak ditandai.

Daripada mencoba melakukan ini di lapisan teks, saya pikir kita perlu berjalan di struktur pohon dan membuat simpul berdasarkan itu, mengatur properti ARIA pada elemen yang kita hasilkan. Struktur pohon dapat mereferensikan data baik di lapisan teks maupun anotasi. Kita dapat mengurutkan ulang teks dan lapisan anotasi node DOM berdasarkan struktur pohon (mungkin rumit tanpa merusak rendering visual?) atau menggunakan aria-owns untuk menyusun ulang hanya pohon a11y tanpa menyusun ulang DOM.

Secara arsitektur, ini rumit karena teks dan lapisan anotasi sudah dirender secara terpisah, dan sekarang kita perlu melihat lapisan ketiga (atau setidaknya sumber kebenaran), struktur pohon, yang dapat memindahkan (atau referensi) node di kedua lapisan lainnya. Cara paling sederhana untuk melakukannya mungkin dengan melampirkan id ke setiap urutan konten yang ditandai (di lapisan teks) dan bidang tautan/formulir (di lapisan anotasi). Saya melihat bidang formulir sudah memiliki atribut data yang menentukan id. Jika kita akan menggunakan aria-owns, kita perlu mengatur atribut id, jadi ini mungkin memberi makan dua burung dengan satu scone. Id harus berupa sesuatu yang dapat kita hitung dari luar lapisan teks dan anotasi, dari dalam lapisan struktur baru kita. Saat kami menangani struktur pohon, kami kemudian akan menampilkan elemen untuk elemen struktur, memindahkan/memiliki elemen dari lapisan teks/anotasi berdasarkan id mereka.

Melampaui tag PDF ke heuristik, kita harus dapat melakukan hal-hal seperti: diberikan tautan atau anotasi bidang formulir, apakah persegi panjangnya mencakup sesuatu di lapisan teks? jika ya, anotasi harus dikaitkan dengan teksnya (aria-owns atau DOM move). Sekali lagi, itu rumit secara arsitektur karena lapisan teks dan anotasi (dan inputnya) terpisah dan saya rasa kita tidak memiliki status cache dari lapisan tersebut yang dapat kita gunakan. Namun, kita berpotensi dapat melihat batas node yang diberikan oleh teks dan lapisan anotasi, meskipun itu mulai mengaburkan batas arsitektur antara konten dan pemrosesan presentasi.

Meskipun implementasi awal dari tag PDF tidak perlu mendukung heuristik, saya sangat menganjurkan ini untuk dipertimbangkan sebagai bagian dari desain arsitektur. Kenyataannya adalah bahwa PDF yang tidak ditandai sayangnya sangat umum dan akan menyedihkan untuk dikunci ke dalam arsitektur yang tidak memungkinkan ini dibuat lebih mudah diakses. (Perhatikan bahwa Acrobat Reader, dan pada tingkat yang jauh lebih rendah Chromium, menggunakan heuristik untuk mencoba membuat PDF yang tidak ditandai lebih mudah diakses.)