Taggart

‏PDF/UA, ‏WCAG ותקן 5568: מה ההבדל ומה צריך

שלושה תקנים שמוזכרים יחד ואומרים דברים שונים. מה כל אחד בודק, מה רק אחד מהם מכסה, ולמה ״לעמוד ב‑WCAG ולבדוק מול PDF/UA״ היא העבודה בפועל.

התשובה הקצרה

• WCAG 2.1 / 2.0 ברמה AA — מה שהחובה מצטטת, כמעט תמיד. ניטרלי לטכנולוגיה: נכתב לאתרים, מוחל על מסמכים באנלוגיה, ואומר מה צריך להיות נכון בלי לומר איך PDF מבטא את זה.
• PDF/UA-1 ‏(ISO 14289-1) — תקן פורמט. אומר בדיוק אילו אובייקטים ב‑PDF חייבים להתקיים ואיך הם קשורים. הוא היחיד מהשניים שבודק יכול לבדוק מכנית, כי הוא מדבר על הקובץ ולא על החוויה.
• תקן ישראלי 5568 — מבוסס על WCAG 2.0 ברמה AA, עם תוספות ישראליות. זה מה שהחובה בישראל מפנה אליו. ← תקן 5568 ומסמכי PDF

הם לא חלופות. בפועל: עומדים ב‑WCAG ובתקן 5568 כי זו החובה, ובודקים מול PDF/UA כי זו הבדיקה.

מה רק WCAG מכסה

כשלים אמיתיים במסמכים אמיתיים, שאף בודק PDF/UA לא ידווח עליהם:

• ניגודיות צבעים (1.4.3). אין ב‑PDF/UA כלום על ניגודיות. מסמך יכול לעבור בדיקה מושלמת עם טקסט אפור בניגודיות 2:1.
• צבע כסימן יחיד (1.4.1). גרף שהמקרא שלו הוא צבע בלבד.
• מטרת הקישור (2.4.4). PDF/UA דורש שלקישור יהיה תיאור. WCAG דורש שהתיאור יאמר לאן הוא מוביל. ״לחצו כאן״ עומד בראשון ולא בשני.
• סדר משמעותי (1.3.2). PDF/UA דורש שיהיה סדר קריאה; WCAG דורש שהוא יהיה הנכון — הכרעה שאף בודק לא מקבל.
• טקסט חלופי שמעביר את המטרה (1.1.1). PDF/UA דורש שיהיה טקסט חלופי לא ריק. אם הוא אומר משהו — זו שאלה של WCAG, ושל אדם.

מה רק PDF/UA מכסה

מנגנונים ספציפיים ל‑PDF, שאין ל‑WCAG שפה עבורם:

• מיפוי תפקידים. תגיות מותאמות חייבות להתמפות לסוגים תקניים (02-001).
• המזהה של PDF/UA במטא‑דאטה (06-002) — הצהרה קריאה למכונה, בלי שום השפעה על החוויה.
• DisplayDocTitle (07-001) — שקובע אם שורת הכותרת מציגה את שם המסמך או את שם הקובץ. ← כותרת ושפה
• כללי קינון של תוכן אמיתי ו‑Artifact, מיפוי תווים ל‑Unicode, הטמעת גופנים.

לחלק מאלה אין השפעה על שום קורא מסך. הם המנגנון שהופך את ההצהרה לבדיקה.

איפה הם חופפים — וזה רוב העבודה

מבנה, סדר, חלופות ושפה הם העיקר בשניהם. תנאי הכשל של פרוטוקול Matterhorn נושאים מיפוי מפורש ל‑WCAG בדיוק מהסיבה הזו: סדר קריאה (09-001) ממופה ל‑1.3.2, דילוג בכותרות (14-003) ל‑1.3.1.

עבדו על PDF/UA-1 כמו שצריך — והחפיפה מטופלת. מה שנשאר ל‑WCAG הוא ניגודיות, מטרת קישורים, והשאלה אם החלופות שכתבתם אומרות משהו. כלומר, החלק שתמיד היה צריך אדם.

והעברית

אף אחד מהשלושה לא בודק באיזה כיוון נשמרו האותיות. לכן קובץ עברי ששמור הפוך עובר כל בודק PDF/UA — veraPDF, ‏PAC, האקרובט — ונכשל בדרישה הבסיסית ביותר של WCAG ושל תקן 5568: שאפשר לקרוא אותו. זו בדיקה נפרדת. ← עברית הפוכה ב‑PDF

מה Taggart בודק

שלושה פרופילים לבחירה: PDF/UA-1, ‏WCAG 2.1 AA ותקן 5568 — ובכולם גם את כיוון העברית והערבית. כל כשל מדווח לפי מספר התנאי ב‑Matterhorn, עם הקריטריון המקביל ב‑WCAG. הוא לא קובע שמסמך ״עומד בתקן״ — זו קביעה של מורשה נגישות.

עוד בנושא

• תקן נגישות 5568 ומסמכי PDF: מה באמת נדרשתקן נגישות 5568 ומה שהוא אומר על מסמכים: מה ניתן לבדוק אוטומטית, מה דורש מורשה נגישות, ולמה מסמכים בעברית נכשלים אחרת.
• דוח הנגשה למסמך: מה צריך להיות בוהקובץ המתוקן הוא מה שהקוראים מקבלים; הדוח הוא מה שהארגון צריך כשמגיעה תלונה. שבעה חלקים שהופכים דוח לכזה שאפשר להגן עליו — ומה ״וי ירוק״ לא אומר.
• בדיקת נגישות PDF בחינם: איך יודעים אם קובץ נגישבדיקת נגישות לקובץ PDF בלי לשלם: ארבע דרכים לבדוק מול PDF/UA ותקן 5568, מה כל אחת תופסת, ומה אף אחת מהן לא יכולה לראות.

תנאי כשל קשורים

העמודים הטכניים המלאים באנגלית, עם קטעי קוד ופתרונות ב‑Acrobat.

• 09-001 Tags are not in logical reading order
• 14-003 Numbered heading levels in descending sequence are skipped
• 07-001 ViewerPreferences does not contain DisplayDocTitle
• 06-002 XMP metadata does not include the PDF/UA identifier
• TG-RTL-001 Right-to-left text is stored in visual order

עודכן לאחרונה 2026-09-27. אין באמור ייעוץ משפטי.