Pdf.js: टैग की गई PDF के लिए समर्थन शामिल करें

[ट्राएज-आवश्यक] लेबल जोड़ा गया। क्या हमें टैग किए गए PDF से संबंधित विकास के लिए एक नए लेबल (4-टैग-पीडीएफ) की आवश्यकता है?

क्या हमारे पास 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"

शुक्रिया! उस मामले में, इस पर गौर करना निश्चित रूप से दिलचस्प है।

मुझे लगता है कि एचटीएमएल और एआरआईए विशेषताओं के मिश्रण का उपयोग करके इसे कार्यान्वित करना अपेक्षाकृत आसान हो सकता है - प्रतिपादन में कोई बदलाव आवश्यक नहीं है - बस कुछ नई विशेषताएं जोड़ें।

पीडीएफ टैगिंग जानकारी को स्ट्रक्चर ट्रीरूट ट्री में संग्रहित किया जाता है, जिसमें एक्सेसिबिलिटी जानकारी जैसे कि ऑल्ट टेक्स्ट, भाषा और सिमेंटिक टाइप (H1, TH, LI, आदि) के साथ स्ट्रक्चर एलिमेंट होते हैं। संरचना तत्वों में पृष्ठ सामग्री स्ट्रीम में वस्तुओं के संदर्भ होते हैं। इसे यहाँ दिखाने वाला एक ग्राफिक है:
https://stackoverflow.com/a/34047585

मुझे लगता है कि आप कुछ इस तरह का उपयोग करके पीडीएफ टैगिंग जानकारी को _layoutText(textDiv) में इंजेक्ट कर सकते हैं:

1) पीडीएफ ऑब्जेक्ट को रेंडर करने के लिए स्ट्रक्चर ट्रीरूट ट्री में संबंधित स्ट्रक्चर एलिमेंट को देखें
2) यदि संरचना तत्व में H1, H2, LI आदि जैसे संरचना प्रकार हैं, तो div में role विशेषता जोड़ें।
3) यदि संरचना तत्व में /Alt प्रविष्टि है, तो div में aria-label विशेषता जोड़ें
4) संरचना प्रकार H1-H6 . के लिए शीर्षक स्तर के अनुरूप div में aria-level विशेषता जोड़ें

इससे शीर्षकों, सूचियों और छवियों को स्क्रीन रीडर के लिए सुलभ बनाना चाहिए। टेबल्स लागू करने के लिए और अधिक जटिल हो सकता है।

पीडीएफ संरचना प्रकार 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-टैग-पीडीएफ लेबल हटा दिया गया है। क्या यह अभी भी कुछ ऐसा है जिसका पीछा किया जा रहा है?

मुद्दा खुला होना दर्शाता है कि हम इस पर विचार कर रहे हैं। यह एक विशेषता है, और लेबलों को थोड़ा सा पुन: व्यवस्थित किया गया है।

वाह बहुत अच्छा! क्या इस सुविधा पर विचार किया जा रहा है, इसमें टैग की गई पीडीएफ़ जनरेट करने के लिए समर्थन शामिल है? यह मौजूदा PDF के लिए पार्सर/विश्लेषक जैसी किसी चीज़ को लागू करने में सुविधा प्रदान कर सकता है, लेकिन यह 508c PDF बनाने के लिए भी सहायता प्रदान करेगा।

508c PDF बनाने के लिए आवश्यक मुख्य कार्यक्षमता:

• दस्तावेज़ को टैग करें (भाषा और शीर्षक के साथ, संभवतः अन्य टैग के साथ)
• पीडीएफ के अंदर संरचनात्मक वस्तुओं को टैग करें (हेडर, टेबल, वें, टीडी, सूचियां, आदि)
• विज़ुअल मीडिया में वैकल्पिक टेक्स्ट जोड़ें (छवियां, वीडियो, आंकड़े, आदि)
• तत्वों का एक टैब क्रम बनाएं/बनाए रखें

यदि इन 4 चीजों के लिए मुख्य कार्यक्षमता मौजूद है, तो पीडीएफ पीढ़ी की प्रक्रिया में तर्क को लागू करना संभव होगा जो 508c पीडीएफ का उत्पादन करेगा। जो, ईमानदार होने के लिए, बहुत बड़ा होगा, क्योंकि मुझे अभी तक इस कार्यक्षमता के साथ कोई ओपनसोर्स जावास्क्रिप्ट टूल नहीं मिला है।

इसे लिखने के बाद, मुझे यकीन नहीं है कि यह एक अलग सुविधा अनुरोध के रूप में योग्य होगा या नहीं ... अगर ऐसा है तो मैं खुशी से एक नया मुद्दा बनाऊंगा।

मैं WCAG 2.0 के SC 2.4.10 और 1.1.1 के साथ बेहतर अनुपालन प्रदान करने के लिए @cuhaller के साथ काम कर रहा हूं, जिस ऐप पर उनकी टीम काम कर रही है।

मेरा मानना ​​​​है कि इस मुद्दे को करने की आवश्यकता के सबसेट के लिए परिवर्तन पर्याप्त होना चाहिए। मैं योगदान दिशानिर्देशों का पालन ​​करते हुए अगले सप्ताह या उसके बाद एक पीआर अप करूंगा। सबमिट करने पर मैं इस थ्रेड को अपडेट कर दूंगा।

मेरे पास इस रेपो के img-alt-text शाखा में स्थित शीर्षक स्तर और वैकल्पिक छवि पाठ (बिना स्थिति के) प्रदान करने के लिए PDF.js के 2.3.200 से एक कांटा में परिवर्तन हैं।

मुझे पीआर खोलने में संकोच हो रहा है क्योंकि मास्टर के खिलाफ मर्ज विवाद हैं और मेरे पास वर्तमान में उन्हें हल करने का समय नहीं है।

अगर किसी के पास इस शाखा को मास्टर के साथ अद्यतित करने की उपलब्धता है तो आइए संपर्क करें!

एज ने टैग किए गए पीडीएफ के लिए मूल समर्थन दिया है। क्रोम भी अब इसका समर्थन करता है, और वेब पेजों से टैग किए गए पीडीएफ को निर्यात करने की अपनी आने वाली क्षमता को भी टाल दिया है।

आज, फ़ायरफ़ॉक्स पीडीएफ में टैगिंग को एक्सेसिबिलिटी ट्री / एक्सेसिबिलिटी एपीआई में उजागर नहीं करता है। हालाँकि, यह पाठ फ़ायरफ़ॉक्स 80 के लिए सुविधाओं की सूची में है :

फ़ायरफ़ॉक्स को अब डिफ़ॉल्ट सिस्टम पीडीएफ व्यूअर के रूप में सेट किया जा सकता है।

यदि कोई उपयोगकर्ता जो AT पर निर्भर है, ऐसा करता है, या एक सिस्टम व्यवस्थापक जो उपयोगकर्ताओं के मेकअप को नहीं जानता है, तो यह उन उपयोगकर्ताओं के लिए समस्याग्रस्त हो सकता है जो अन्यथा एज, क्रोम या एडोब के रीडर पर निर्भर थे, उनके लिए टैग की गई पीडीएफ को पार्स करना .

मैं दृढ़ता से सुझाव देता हूं कि 80 के रिलीज नोट्स से सलाह को हटा दिया जाए, और इस बग प्राथमिकता को बढ़ा दिया जाए। मैं समझता हूं कि मोज़िला अब संसाधन की कमी है, लेकिन एक दुर्गम सुविधा को बढ़ावा देने पर प्रकाशिकी जो प्रतिस्पर्धी ब्राउज़रों में बेहतर सेवा प्रदान करती है, एक अच्छी नज़र नहीं है।

हमारा संगठन सहायक तकनीकों के उपयोगकर्ताओं के लिए एक सुलभ पीडीएफ समाधान लागू करना चाहता है। हम इस निष्कर्ष पर पहुंचे हैं कि पीडीएफ जेएस के साथ पीडीएफ का पूर्वावलोकन करना सुलभ नहीं है क्योंकि सिमेंटिक मार्कअप गायब है। सिमेंटिक जानकारी का अभाव स्क्रीन रीडर सॉफ़्टवेयर के साथ इंटरैक्ट करने वाले उपयोगकर्ताओं के लिए अवरोध पैदा करता है। जबकि पीडीएफ सादे पाठ में प्रदर्शित होता है और एनोटेशन की घोषणा करता है, शीर्षकों, तालिकाओं, छवियों या लिंक के लिए मार्कअप की आपूर्ति नहीं की जाती है।

स्क्रीन रीडर उपयोगकर्ताओं के लिए टेबल के आस-पास का उपयोग केस विशेष रूप से कठिन है। जिन तालिकाओं में सिमेंटिक मार्कअप नहीं है, वे उपयोगकर्ताओं को कोई संदर्भ नहीं देते हैं और स्क्रीन रीडर उपयोगकर्ताओं के लिए पीडीएफ में प्रस्तुत जानकारी को पूरी तरह से समझना असंभव है।

लिंक को विशिष्ट लिंक टेक्स्ट के बजाय URL के रूप में घोषित किया जाता है जिससे लिंक के उद्देश्य को समझना मुश्किल हो जाता है। हम अनुशंसा करेंगे कि लिंक लिंक URL के बजाय दृश्यमान लिंक टेक्स्ट का उपयोग करें, ताकि उपयोगकर्ता लिंक को संदर्भ में समझ सकें।

इस समर्थन के बिना, हमें पीडीएफ जेएस को व्यापक रूप से लागू करने की चिंता है। क्या सिमेंटिक मार्कअप प्रदान करने के लिए किसी फीचर को सपोर्ट करने के लिए कोई अपडेट या टाइमलाइन है? हम चाहते हैं कि इस मुद्दे को एक उच्च प्राथमिकता के रूप में माना जाए क्योंकि यह सामग्री को देखने और बातचीत करने की उपयोगकर्ताओं की क्षमता को प्रभावित करता है।

जहाँ तक मुझे पता है, योगदान स्वागत से अधिक है

इस पर आपके काम के लिए धन्यवाद @trjohnst ।

मैंने pdf.js मास्टर पर @trjohnst की शाखा को मैन्युअल रूप से रीबेस करना शुरू कर दिया। यह दृष्टिकोण उन टैग्स के लिए अच्छा काम करता है जिन्हें केवल एक स्तर की आवश्यकता होती है; उदाहरण के लिए शीर्षक या छवियों के साथ वैकल्पिक पाठ। सामग्री स्ट्रीम पर चलते समय, यदि यह एक चिह्नित-सामग्री अनुक्रम का सामना करता है, तो यह संबंधित संरचना तत्व को देखता है और पीडीएफ.जेएस टेक्स्ट लेयर द्वारा HTML आउटपुट में टेक्स्ट स्पैन पर उपयुक्त ARIA भूमिका रखता है।

दुर्भाग्य से, यह नेस्टेड टैग की आवश्यकता वाली किसी भी चीज़ के लिए पर्याप्त नहीं है; उदाहरण के लिए सूचियाँ या तालिकाएँ। मुझे नहीं लगता कि दृष्टिकोण को कवर करने के लिए बढ़ाया जा सकता है, कम से कम बहुत मुश्किल किनारे के मामलों के बिना नहीं। इसके अलावा, लिंक और फ़ॉर्म फ़ील्ड का ठीक से समर्थन करने के लिए (और ध्यान दें कि फॉर्म फ़ील्ड @trjohnst के योगदान के समय pdf.js द्वारा समर्थित नहीं थे), हमें एनोटेशन परत पर विचार करने में सक्षम होना चाहिए, न कि केवल टेक्स्ट लेयर। आगे और भी सोचकर, यह अच्छा होगा कि हेरिस्टिक्स को लागू करने में सक्षम होने के लिए (और सही स्थिति) शीर्षकों, लिंक, टेबल, फॉर्म फ़ील्ड इत्यादि का पता लगाने का प्रयास करें।

टेक्स्ट लेयर में ऐसा करने की कोशिश करने के बजाय, मुझे लगता है कि हमें स्ट्रक्चर ट्री पर चलना होगा और उसके आधार पर नोड्स को रेंडर करना होगा, हमारे द्वारा आउटपुट किए जाने वाले एलिमेंट्स पर ARIA प्रॉपर्टीज सेट करना। स्ट्रक्चर ट्री टेक्स्ट और एनोटेशन लेयर दोनों में डेटा को रेफर कर सकता है। हम या तो स्ट्रक्चर ट्री के आधार पर टेक्स्ट और एनोटेशन लेयर DOM नोड्स को फिर से व्यवस्थित कर सकते हैं (विजुअल रेंडरिंग को तोड़े बिना मुश्किल हो सकता है?)

वास्तुकला की दृष्टि से, यह मुश्किल है क्योंकि पाठ और एनोटेशन परतें पहले से ही अलग-अलग प्रस्तुत की गई हैं, और अब हमें एक तीसरी परत (या कम से कम सत्य का स्रोत), संरचना वृक्ष को देखने की आवश्यकता है, जो दोनों में नोड्स को स्थानांतरित (या संदर्भ) कर सकता है। अन्य परतें। ऐसा करने का सबसे आसान तरीका शायद प्रत्येक चिह्नित-सामग्री अनुक्रम (पाठ परत में) और लिंक/फॉर्म फ़ील्ड (एनोटेशन परत में) में एक आईडी संलग्न करना है। मुझे लगता है कि फॉर्म फ़ील्ड में पहले से ही एक आईडी निर्दिष्ट करने वाली डेटा विशेषता है। यदि हम एरिया-ओन का उपयोग करने जा रहे हैं, तो हमें वैसे भी आईडी विशेषता सेट करने की आवश्यकता है, ताकि यह दो पक्षियों को एक स्कोन से खिला सके। आईडी को कुछ ऐसा होना चाहिए जिसकी गणना हम पाठ और एनोटेशन परतों के बाहर से कर सकें, हमारी नई संरचना परत के भीतर से। जब हम स्ट्रक्चर ट्री को हैंडल कर रहे होते हैं, तब हम स्ट्रक्चर एलिमेंट्स के लिए एलिमेंट्स को आउटपुट करते हैं, तत्वों को उनके आईडी के आधार पर टेक्स्ट/एनोटेशन लेयर्स से मूविंग/स्वामित्व करते हैं।

टैग की गई पीडीएफ से लेकर अनुमान तक, हमें कुछ ऐसा करने में सक्षम होना चाहिए जैसे: एक लिंक या फॉर्म फ़ील्ड एनोटेशन दिया गया है, क्या इसकी आयत में टेक्स्ट लेयर में कुछ शामिल है? यदि ऐसा होता है, तो एनोटेशन को इसके टेक्स्ट (एरिया-स्वामित्व या डोम चाल) के साथ जोड़ा जाना चाहिए। फिर, यह वास्तुशिल्प रूप से मुश्किल है क्योंकि पाठ और एनोटेशन परतें (और उनके इनपुट) अलग हैं और मुझे नहीं लगता कि हमारे पास उन परतों से कोई कैश्ड स्थिति है जिसका हम उपयोग कर सकते हैं। हालांकि, हम संभावित रूप से टेक्स्ट और एनोटेशन परतों द्वारा प्रदान किए गए नोड्स की सीमाओं को देख सकते हैं, हालांकि यह सामग्री और प्रस्तुति प्रसंस्करण के बीच वास्तुशिल्प सीमाओं को धुंधला करना शुरू कर देता है।

जबकि टैग की गई पीडीएफ के प्रारंभिक कार्यान्वयन के लिए जरूरी नहीं कि हेरिस्टिक्स का समर्थन करने की आवश्यकता हो, मैं इसे वास्तुशिल्प डिजाइन के हिस्से के रूप में माना जाने के लिए दृढ़ता से प्रोत्साहित करता हूं। वास्तविकता यह है कि अचिह्नित पीडीएफ दुर्भाग्य से बहुत प्रचलित हैं और यह एक ऐसी वास्तुकला में बंद होना दुखद होगा जो इन्हें और अधिक सुलभ बनाने की अनुमति नहीं देता है। (ध्यान दें कि एक्रोबैट रीडर, और काफी हद तक क्रोमियम, बिना टैग की गई PDF को अधिक सुलभ बनाने के लिए हेरिस्टिक्स का उपयोग करते हैं।)