In my recent article, The next big leap in digital accessibility: Why the digital accessibility community should embrace EN 17161 Design for All, I discussed the differences between output and management standards, and specifically detailed how WCAG (an output standard) has limitations that can be offset by partnering it with EN 17161 (a management standard).
In this article, I’m going to explore another challenge associated with WCAG adoption—its single-page, point-in-time, all-or-nothing conformance model. And I will again present EN 17161 as the solution.
WCAG’s unrealistic conformance
WCAG is written to apply to individual web pages, and a single web page is considered the “unit of conformance.” You cannot exclude sections of a page when claiming conformance, nor can you say a whole website conforms to WCAG. The most you could say is that every page of a website conforms to WCAG. This is, in fact, what web accessibility laws in many places require—that all pages conform to WCAG (or a standard built on WCAG).
For many sites, full conformance to WCAG is effectively impossible.
This isn’t a question of effort, awareness, or better safeguards. The reality is that humans and AI systems both make mistakes, and any larger site is inevitably going to have bugs. On top of that, many sites include third-party content that they don’t control.
The question then becomes, how close to full conformance are you? Unfortunately, WCAG doesn’t help us to answer that question. WCAG has levels of conformance, but it’s not the case that all sites first meet level A, then level AA, and eventually level AAA. Bugs come up at any level. You aren’t going to fall down a level if things get worse. You just don’t conform.
Counting the number of WCAG criteria met isn’t much better. The spread between criteria is very uneven. From a user experience and accessibility standpoint, a site that fails three criteria could be in a great or terrible state, depending on which three criteria are failed, and how those failures impact users.
None of this is meant to suggest, by the way, that WCAG’s conformance model is a bad one. On the contrary, I really like it. It’s great for what it does. It just isn’t up to addressing challenges that modern websites face, and efforts to improve this situation have met with little success. WCAG is a fantastic tool for individual-page accessibility. But when it comes to managing millions of dynamic pages, an Integrated Management System (IMS) is a far better choice.
EN 17161 Design for All is a management standard that describes how organizations can build and deliver accessible products, goods, and services. It focuses on helping organizations establish processes to ensure user needs are considered throughout planning, design, development, and delivery. It is designed to pair with ISO 9001 (likely the best-known IMS), which requires what I call issue registries.
Issue registries
Solving the challenges I’ve outlined above requires setting goals for accessibility. You need to identify where your organization is weak, so that you can focus efforts on those areas. From there, you need to do the work and have performance indicators in place to measure success rates. This is known as the plan-do-check-act cycle which many management standards use.
An issue registry is a list of identified accessibility issues that includes information about what caused each issue and what will be done about it. Many organizations already have a list of issues—an issue registry takes this a step further.
Your issue registry should be a system-wide or organization-wide view of accessibility. It should include issues from automated monitoring and expert audits, as well as customer feedback, usability results, and customer support issues. Layered on top of this, there should be a root cause analysis (RCA) that provides insight into common causes and helps you understand what causes issues, and where your testing strategy may be slow to detect them. The registry can also contain corrective and preventive action (CAPA), so you can track how successful you are at resolving issues in the expected timeline.
Accessibility goals
With an accessibility issue registry in place, organizations can then set goals for them. This involves defining impact; for instance, an organization may distinguish between blockers and hindrances, and separate core functionality from secondary features.
You can set goals such as:
- Resolve blocking issues in core systems within two weeks of detection.
- Resolve other accessibility issues within three months of detection.
- Ensure that 90% of detected issues are less than six months old.
- Reduce newly detected issues by 20% every six months.
You’ll want goals that create tension between content creation, issue detection, and remediation. To detect issues quickly, you’ll need to test regularly using different methods (automated, manual, usability). With regular testing, detecting fewer issues can only be achieved by improving the content creation process. Regular testing also fills the remediation pipeline, requiring that adequate resources are allocated to address the issues on time.
Continually meeting these goals means evaluating which parts of the process are weakest, and coming up with ways to improve on them. Only then can you stay on track for those goals.
Adoption of EN 17161
The way I think of the relationship between WCAG and EN 17161 is that WCAG is the horizon. It is the direction you’re traveling in, and even if you can’t actually “reach” the horizon, it’s what you’re driving toward. EN 17161 is the road you drive on, and it has all the markings, guides, and signs that keep you on track and prevent you from swerving into other traffic or a ditch.
EN 17161 was first published in 2019, with a new version expected sometime later this year. So far, it has not seen anywhere near the level of adoption that WCAG had in its first five years. There are some understandable reasons for this, with WCAG’s enormous success being the most obvious one—with WCAG in place, not many in the digital accessibility field have seriously explored other options. Adding to the challenge, EN 17161 (like many CEN/CENELEC standards) isn’t a free and open standard. Despite this, I believe it can help us tackle many of the largest problems in digital accessibility.
I mentioned in my previous post that the W3C is also focused on problem-solving, and hopes to address many of the existing gaps I’ve been flagging with WCAG 3.0. So you might be wondering, shouldn’t we just wait for WCAG 3.0?
The wait for WCAG 3.0
WCAG 3.0 will be a complete rewrite of WCAG 2.2 and will include many new requirements. It will still be written for the web, but it may include provisions that can be used with non-web technologies. The W3C also aims to develop a conformance model better suited to today’s dynamic web. It may, for instance, include a scoring model, and come with authoring tool requirements for third-party content providers.
The reality, however, is that WCAG 3.0 is at least four years away from completion. This is one of many reasons why I believe we need EN 17161 today.
While a lot of progress has been made, the parts of WCAG 3.0 that are the least well-defined are those focused on the most difficult issues—which is not surprising. As I’ve explained previously, WCAG—as an output standard—just isn’t well-suited to address these types of issues.
Embracing EN 17161
Fortunately, WCAG 3.0 doesn’t need to solve every problem in digital accessibility. The EU has done a fantastic job building its standards on top of WCAG. EN 301 549 (which currently references WCAG 2.1, with adoption of WCAG 2.2 expected this fall) uses it for web, and expands on it for documents, apps, kiosks, and more. With EN 17161, the EU has a standard that extends accessibility beyond digital and building codes, to help tackle organizational obstacles.
I believe the W3C’s best bet for a robust WCAG 3.0 equipped to handle all these challenges is to lean in and embrace EN 17161. Don’t double up on or contradict its requirements, and make its adoption an easy, natural part of adopting WCAG 3.0.
Another reason to embrace EN 17161 right now is that it’s already being folded into the European Accessibility Act. Organizations that operate in Europe may already need EN 17161 to meet some of its requirements.
Meet EAA requirements with EN 17161 Design for All
The European Accessibility Act (EAA) requires digital products and services to be accessible. A common misconception is that this means that the EAA requires WCAG conformance. The reality is a little more complicated.
EN 301 549, the EU’s output standard for digital accessibility, does incorporate WCAG. But the EAA requires quite a few other things as well, for which other standards are being written or updated. The next version of EN 17161, predictably, is focused on compliance with EAA’s process requirements.
And yes, you read that right. The EAA has process requirements! Accessibility under the EAA isn’t only about digitally accessible content. There are also requirements around procurement, support, accessibility statements, and more. That’s where EN 17161 fits in.
According to the European Disability Forum, EN 17161 is under review for approval as a harmonized EU standard. If it gets approved, EN 17161 will become the accepted standard for complying with those EAA process requirements. So, while the EAA doesn’t strictly require EN 17161, adopting it now is already the best way to meet some of EAA’s requirements.
Next steps
If you’re in a position to drive adoption at your organization, I’d strongly recommend considering EN 17161 now. To get started, focus on leadership buy-in first. If your organization uses ISO 9001 for quality, ISO 27001 for security, or something similar, you can also talk to the people running those programs. If you have anything to do with procurement, you can also consider asking organizations to demonstrate adoption of EN 17161 (in addition to asking for an audit against EN 301 549). And if you’re in the US and involved in an ADA lawsuit, you might consider adopting EN 17161 as part of the settlement.
Partnering EN 17161 with WCAG
Here and in my previous article on this topic, I’ve argued for two standards instead of one. WCAG can tell you whether your content is accessible today. EN 17161 can help you build an organization that keeps it that way—while also handling disability needs that WCAG doesn’t cover. Neither one does the whole job by itself, but together, they enable you to truly manage all of digital accessibility’s complexities. Partnering EN 17161 with WCAG is a major step forward from where we are today. Everything we need is there; we just have to embrace it.
