Skip to content

Add WCAG2.2 PDF2.0 flavours#1564

Merged
MaximPlusov merged 1 commit intointegrationfrom
wcag_2_0
Nov 27, 2025
Merged

Add WCAG2.2 PDF2.0 flavours#1564
MaximPlusov merged 1 commit intointegrationfrom
wcag_2_0

Conversation

@MaximPlusov
Copy link
Copy Markdown
Contributor

@MaximPlusov MaximPlusov commented Nov 21, 2025

Summary by CodeRabbit

  • New Features

    • Added WCAG 2.2 coverage with a PDF 2.0–specific variant (both human and machine profiles) for accessibility validation.
  • Enhancements

    • Improved detection of PDF/UA and WCAG-related compliance variants to more accurately classify documents.
    • Updated flavour/part identification and ID construction to support PDF 2.0–specific behavior.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Nov 21, 2025

Walkthrough

Adds two WCAG 2.2 PDF‑2.0 flavour constants (human/machine), introduces PDFAFlavours.PDF_2_0_PART, adjusts Specification mappings (WCAG_2_2 → ISO_32000_1_7; new WCAG_2_2_PDF_2_0 → ISO_32000_2_0), and updates flavour ID construction plus PDF‑UA related checks.

Changes

Cohort / File(s) Change Summary
WCAG 2.2 flavours & ID logic
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java
Added enum constants WCAG_2_2_PDF_2_0_HUMAN and WCAG_2_2_PDF_2_0_MACHINE; getID() now appends PDFAFlavours.PDF_2_0_PART when standard == Specification.WCAG_2_2_PDF_2_0.
Specification additions / mapping
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java
Changed Specification.WCAG_2_2 to use PDFSpecification.ISO_32000_1_7; added Specification.WCAG_2_2_PDF_2_0 using PDFSpecification.ISO_32000_2_0 with same flavour associations.
PDF 2.0 part constant
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavours.java
Added static final String PDF_2_0_PART = "2"; for constructing PDF‑2.0 flavour IDs.
PDF‑UA related flavour checks
core/src/main/java/org/verapdf/pdfa/flavours/PDFFlavours.java
isPDFUA1RelatedFlavour updated to accept PDFUA_1 or WCAG parts via isFlavourPart; isPDFUA2RelatedFlavour updated to include the WCAG_2_2_PDF_2_0 part check.

Sequence Diagram(s)

sequenceDiagram
  participant Caller
  participant Flavour as PDFAFlavour
  participant Const as PDFAFlavours

  Caller->>Flavour: getID()
  alt standard == WCAG_2_2_PDF_2_0
    Flavour->>Const: read PDF_2_0_PART ("2")
    Flavour-->>Caller: return baseID + "-" + "2"
  else other standard
    Flavour-->>Caller: return baseID
  end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Check enum additions for ordering/serialization effects in PDFAFlavour.
  • Verify Specification.WCAG_2_2 and new WCAG_2_2_PDF_2_0 use correct PDFSpecification values and descriptions.
  • Confirm getID postfix logic and consistent use of PDFAFlavours.PDF_2_0_PART.
  • Review PDFFlavours.isPDFUA1RelatedFlavour / isPDFUA2RelatedFlavour changes for correctness and coverage.

Poem

🐰 I hopped through enums, found two new friends,
One wears old ink, one a PDF‑2.0 trend.
A tiny "-2" stitched to the name,
IDs aligned, the flavours came.
Hop, test, release — I nibble and send. 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately reflects the primary change: adding WCAG 2.2 with PDF 2.0 variant support (WCAG_2_2_PDF_2_0_HUMAN and WCAG_2_2_PDF_2_0_MACHINE constants) to the PDFAFlavour enum.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch wcag_2_0

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 34b3c38 and 2b23197.

📒 Files selected for processing (2)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (2 hunks)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFFlavours.java (2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavours.java (1)
  • PDFAFlavours (34-116)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFFlavours.java (1)

49-52: UA1/UA2 mapping logic is consistent with the new WCAG 2.2 PDF 1.7 / 2.0 split, but sensitive to flavour-id clashes

The revised helpers look logically sound:

  • isPDFUA1RelatedFlavour now treats:

    • PDFUA_1 itself, plus
    • WCAG flavours whose part is Specification.WCAG_2_1 or Specification.WCAG_2_2 (your PDF 1.7 WCAG 2.2 spec)
      as UA1-related.
  • isPDFUA2RelatedFlavour now treats:

    • PDFUA_2,
    • Specification.WTPDF_1_0, and
    • Specification.WCAG_2_2_PDF_2_0
      as UA2-related.

Using isFlavourPart(flavour, spec) (enum identity on Specification) keeps these checks precise and future-proof against additional WCAG family members.

However, because the WCAG 2.2 1.7 and 2.0 flavours currently share the same string ids ("wcag2h"/"wcag2m") in PDFAFlavour, a flavour obtained via byFlavourId("wcag2h") will be recognized as UA2-related (PDF 2.0 spec), while PDFAFlavour.WCAG_2_2_HUMAN is UA1-related (PDF 1.7 spec). Once the flavour-id collision in PDFAFlavour is resolved, these helpers should behave as intended for both enum-based and string-based flows.

I’d recommend adding/adjusting tests to cover:

  • UA1 vs UA2 classification for:
    • PDFUA_1, PDFUA_2,
    • WCAG 2.1,
    • WCAG 2.2 (PDF 1.7),
    • WCAG 2.2 PDF 2.0, and WTPDF 1.0.
  • The behaviour when flavours are sourced via PDFAFlavour.byFlavourId / fromString rather than direct enum references.

Also applies to: 65-66

@MaximPlusov MaximPlusov force-pushed the wcag_2_0 branch 2 times, most recently from fd7753f to 94334f4 Compare November 23, 2025 09:40
Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (1)

220-226: Specification id and name duplication between WCAG_2_2 and WCAG_2_2_PDF_2_0.

Both Specification.WCAG_2_2 and Specification.WCAG_2_2_PDF_2_0 share the same partNumber (2), subpartNumber (2), year, and description. As a result, calculateID() produces the identical id "WCAG2.2" for both, and the name field is "WCAG-2" for both.

If any code, logging, configuration, or UI relies on Specification.getId() or getName() as unique identifiers, this collision will cause ambiguity — users or systems won't be able to distinguish the PDF 1.7 variant from the PDF 2.0 variant.

Consider one of these approaches:

  1. Use a distinct subpart or series for the PDF 2.0 variant to differentiate at the specification level.
  2. Override or extend calculateID() to include a PDF version marker for specifications that have multiple baseline PDF versions (e.g., append "-pdf17" or "-pdf20").
  3. Introduce an explicit displayName or uniqueId field if id and name must remain the same for compatibility.

For example:

 WCAG_2_2(IsoStandardSeries.NO_SERIES, PDFSpecification.ISO_32000_1_7, SpecificationFamily.WCAG, 
         PDFAFlavours.WCAG_2_2_PART, PDFAFlavours.WCAG_2_2_SUBPART, PDFAFlavours.WCAG_2_2_YEAR, 
         PDFAFlavours.WCAG_2_2_DESCRIPTION),
-WCAG_2_2_PDF_2_0(IsoStandardSeries.NO_SERIES, PDFSpecification.ISO_32000_2_0, SpecificationFamily.WCAG,
-         PDFAFlavours.WCAG_2_2_PART, PDFAFlavours.WCAG_2_2_SUBPART, PDFAFlavours.WCAG_2_2_YEAR,
-         PDFAFlavours.WCAG_2_2_DESCRIPTION);
+WCAG_2_2_PDF_2_0(IsoStandardSeries.NO_SERIES, PDFSpecification.ISO_32000_2_0, SpecificationFamily.WCAG,
+         PDFAFlavours.WCAG_2_2_PART, PDFAFlavours.WCAG_2_2_PDF_2_0_SUBPART, PDFAFlavours.WCAG_2_2_YEAR,
+         PDFAFlavours.WCAG_2_2_DESCRIPTION);

Where WCAG_2_2_PDF_2_0_SUBPART could be a distinct value that produces a unique id like "WCAG2.2-pdf2".

🧹 Nitpick comments (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (1)

131-135: ID collision successfully resolved with postfix logic.

The postfix logic correctly differentiates WCAG 2.2 PDF 1.7 and PDF 2.0 variants:

  • wcag2h / wcag2m for PDF 1.7
  • wcag2h2 / wcag2m2 for PDF 2.0

This resolves the FLAVOUR_LOOKUP collision from the previous review.

The current approach hardcodes the check for WCAG_2_2_PDF_2_0. If additional PDF 2.0 variants are introduced for other WCAG versions, consider extracting the postfix logic into a method that checks a specification property (e.g., requiresPdfVersionPostfix()), or use a naming convention in the specification enum to drive the postfix automatically.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fd7753f and 94334f4.

📒 Files selected for processing (3)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (3 hunks)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavours.java (1 hunks)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFFlavours.java (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavours.java
🧰 Additional context used
🧬 Code graph analysis (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavours.java (1)
  • PDFAFlavours (34-117)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (2)
core/src/main/java/org/verapdf/pdfa/flavours/PDFFlavours.java (2)

64-67: LGTM! Correctly classifies WCAG_2_2_PDF_2_0 as PDF/UA-2 related.

The addition of the WCAG_2_2_PDF_2_0 check properly extends PDF/UA-2 classification to include the new WCAG 2.2 PDF 2.0 flavours.


49-53: I need to examine the UA-2 classification method to fully verify the concern.

Verify the review comment's accuracy regarding PDF/UA-1 classification.

The review comment contains a factual inaccuracy. PDF/UA-2 is based on PDF 2.0, but the codebase data shows that WCAG_2_2 uses PDFSpecification.ISO_32000_1_7 (PDF 1.7), not PDF 2.0.

The actual specification mappings are:

  • WCAG_2_1: PDF 2.0 → classified as PDF/UA-1 related
  • WCAG_2_2: PDF 1.7 → classified as PDF/UA-1 related (consistent with PDF/UA-1 = PDF 1.7)
  • WCAG_2_2_PDF_2_0: PDF 2.0 → classified as PDF/UA-2 related (consistent with PDF/UA-2 = PDF 2.0)

The concern about WCAG_2_1 using PDF 2.0 but being grouped with UA1 may warrant verification, but the review mischaracterizes WCAG_2_2 as using PDF 2.0. Additionally, WCAG 2.1 was published on 5 June 2018, which may explain why a PDF 2.0-based WCAG flavour could reasonably be associated with PDF/UA-1 if the classification is driven by WCAG version semantics rather than the underlying PDF specification version. To confirm whether the classification is intentional domain logic or requires correction, verify the isPDFUA2RelatedFlavour method and understand why WCAG_2_1 was mapped to UA1 despite using PDF 2.0.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavours.java (1)

83-83: LGTM! Constant serves its purpose correctly.

The PDF_2_0_PART constant successfully enables ID differentiation for PDF 2.0 variants in the getID logic.

Optional: The name PDF_2_0_PART might be slightly misleading since surrounding *_PART constants (e.g., WCAG_2_2_PART, ISO_19005_1_PART) are integer part numbers, while this is a String postfix. Consider renaming to PDF_2_0_POSTFIX or PDF_2_0_SUFFIX for clarity, though the current name is acceptable.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 94334f4 and 8e9ffc4.

📒 Files selected for processing (3)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (3 hunks)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavours.java (1 hunks)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFFlavours.java (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • core/src/main/java/org/verapdf/pdfa/flavours/PDFFlavours.java
🧰 Additional context used
🧬 Code graph analysis (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (1)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavours.java (1)
  • PDFAFlavours (34-117)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (3)
core/src/main/java/org/verapdf/pdfa/flavours/PDFAFlavour.java (3)

102-109: LGTM! Comments and enum declarations are now accurate.

The updated comments correctly distinguish between WCAG 2.2 PDF 1.7 (lines 102-105) and PDF 2.0 (lines 106-109) variants, and the enum declarations properly reference the corresponding Specification constants.


134-135: LGTM! The postfix logic successfully resolves the duplicate ID issue.

The conditional postfix appends "2" to PDF 2.0 variant IDs, ensuring unique flavour identifiers:

  • WCAG 2.2 PDF 1.7: wcag2h, wcag2m
  • WCAG 2.2 PDF 2.0: wcag2h2, wcag2m2

This eliminates the FLAVOUR_LOOKUP collision and ensures byFlavourId() and fromString() return the correct flavours.


222-227: LGTM! Specification mappings correctly reflect PDF baseline differences.

The changes appropriately distinguish the two WCAG 2.2 variants:

  • WCAG_2_2 now maps to ISO_32000_1_7 (PDF 1.7)
  • WCAG_2_2_PDF_2_0 maps to ISO_32000_2_0 (PDF 2.0)

Note: Both specifications share the same calculateID() result ("WCAG2.2") since they have identical part/subpart numbers. This appears intentional—they represent the same WCAG 2.2 standard applied to different PDF versions, with the key differentiation occurring at the PDFAFlavour enum level through the postfix mechanism.

@MaximPlusov MaximPlusov merged commit c48b013 into integration Nov 27, 2025
8 of 9 checks passed
@MaximPlusov MaximPlusov deleted the wcag_2_0 branch December 3, 2025 21:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant