Updating PatternFly A11y standards to WCAG 2.2 (Part 1)

[thatblindgeye]

1. Problem Statement & Goal

As of August 2025, PatternFly has stated that we strive for 2.1 AA WCAG compliance. However, currently IBM has updated their standards to 2.2, and the RHDS is planning to do the same.

• We should aim for parity not only with IBM, but also with the RHDS to better bridge our two design systems
• WCAG 2.2 introduces 9 new guidelines, of which a select few are really more applicable to PatternFly and would help enhance the accessibility
• WCAG 2.2 has been official for a little while now, and we should be aiming for the latest, up-to-date guidelines to follow, especially to help us get in a better spot to eventually update standards when WCAG 3.0 becomes official in the future

2. Scope & Completion

Updating PatternFly standards to WCAG 2.2 AA (and in turn, 2.1 AA) will most likely require multiple epics - especially if breaking changes are needed to be made. This initial epic will be scoped to the following:

• If possible, updating the patternfly-a11y tool to target wcag 2.2 tags by default
• Updating our repos that utilize the tool in CI/CD to the latest release version after the above is completed and released
• Seeing if any new failures get flagged by the tool and either opening issues to resolve them, or adding rules to the ignore array with the intent to revisit them later (breaking change potentially)
• We could also try updating any a11y config files so that an ignore rule array is empty, to double check whether any of the rules are valid to be ignored (i.e. if a rule is giving us a lot of false failures). This will depend on how much time we have left in the quarter, and should be considered a nice-to-have for this epic.
  • The above would also either have issues opened to resolve failures or the rule added back to the ignore array for now

Completion would be defined as having done the above in all repos using our a11y tooling, keeping in mind that actually fixing any issues opened as part of this epic would be tackled by a separate, future epic. This epic is simply assessing what sort of lift will be needed simply by updating our a11y tooling.

Repos to target:

• React
• Core
• Org
• Data view
• Chatbot
• Quickstarts
• Catalog view
• Component groups
• Console
• Log viewer
• Topology
• Virtualized extension
• User feedback
• Design tokens
• AI infra ui components (check if this is expected to be a maintained repo first)
• Extension seed (same as above, check)

3. Risks & Testing

• Risk: larger repos may be more time consuming to sift through any a11y errors that our tool flags, especially if it's to determine whether it's a valid error or a false positive.
• Risk: probably unlikely, but updating the a11y tool version in repos could potentially cause some sort of unforeseen build issues.
• We may need to disable the a11y checks in PRs from blocking merging temporarily while we work on resolving issues, as that's historically what we have had to do

4. Supporting Information & Communication

• Links

  • What's new in WCAG 2.2
  • August 2025 Research doc
  • IBM accessibility requirements

• Communication plan

  • Primarily via epic brief, but a short blog article could be written surrounding the long-term goal, what we tackled as part of this initial epic, and findings/thoughts along the way.

5. Effort & Open Questions

• Estimated Level of Effort: with PatternFly having almost ~20 (I initially counted about 16 give or take) repos we actively maintain that are consumable in some way (+ the react repo having several larger packages within itself), the potential level of effort might be a majority of a quarter.

  • The repos that would most likely be the larger time sinks are core, react, chatbot, and topology
  • The rest of the repos might be quicker to run through, and in the long run issues that are opened in these repos may also be resolved by updates made in the core or react repos themselves.
  • If we assume 16 total repos to tackle, allocating 5 sprints where ~4 repos are tackled each sprint, if we had 1 dev tackling a repo we would only need 4 devs per sprint (1 core + 3 react if possible, though we might be able to do 4 react once the core repo has been marked complete for the purposes of this epic).

• Open Questions

  • What issues that get opened up will need to wait for a breaking change? We won't be able to answer this until the "during execution" phase
  • Do we need to align with RHDS updating their standards/meeting WCAG 2.2, or is it fine as long as both design systems have a plan to strive for 2.2, but not necessarily begin work towards complying with it at the same time? This is something I can discuss with Nina Roby, whom I had a conversation with about the parity between RHDS and PF a11y standards.
  • What do we want the continutation of the overall effort to look like in terms of future epics?
    • Ideally we would have followup epics to tackle resolving issues found from this epic
    • from there additional epics to get a closer look on potential issues our tooling didn't catch (manual audits of components/pages on org, running axe dev tools for more interactive implementations that our a11y tooling can't properly test, seeing if Cursor/AI can flag issues in the actual codebases)
    • overall this should all be a bit more scoped than the a11y audits I previously ran - this overall story is about striving for WCAG 2.2, which has specific guidelines; my previous a11y audits got deeper into issues such as unique aria labeling/attributes and the like that WCAG may not specifically call out