RE: [External] Re: [Protocols] Minutes for March 4th, 2022

Hi all,

Sorry, I’m just getting used to discussing topics in this format (just starting to participate this way), so please let me know if this email doesn’t make sense.

I agree with protocols being more related to the maturity model work. Requiring companies to adopt certain guidelines and leading them in the direction of adopting an accessibility program and/or better accessibility program governance would help move the needle if included along with (but not instead of) clearer pass/fail requirements like WCAG 2.x Success Criteria. Accessibility programs are only effective if they lead to more accessible outcomes. I don’t think anyone here is saying that protocols should replace success criteria (or methods), but complement them (if I’m reading the thread correctly).

In the US, it appears (this is just my own opinion from reviewing resources and in no way should be relied on) people enforce Title III of the ADA by filing lawsuits (which actually doesn’t appear to mention web accessibility at all, some courts have started to interpret parts of Title III to include web accessibility and adherence to WCAG as a measure of how accessible websites are), and while some courts appear to look to an organization’s accessibility program if it does go to court, it looks like most cases don’t get that far. In many cases, it seems like plaintiffs are unable to complete a key workflow in a site and then bring a claim because of that and that claim is settled out of court. For some background, see: and The DOJ also takes action in some cases, and they appear to require conformance to WCAG and require companies to create a basic accessibility program within their organization, see: and,websites%20or%20other%20online%20platforms.

I believe governments in the US have a clearer obligation to make their websites accessible, on the other hand, and are more likely to have further obligations placed on them to adopt robust accessibility programs in the future. Progress has been slower in the private sector sadly, so it seems we have a loose network of court cases and enforcement actions that form our legal framework for requiring web accessibility (with the exception of a few industry-specific laws), so any framework we adopt in the future should just take that into account. I recommend (maybe when we move WCAG 2.x Success Criteria to WCAG 3.0 and after we define protocols), we work with outside groups of lawyers and regulators from different countries to assess the impact the new standards would have on the legal landscape. 😊

For WCAG 3.0, I still think that we should try to make it as easy for non-experts to determine if something’s accessible as possible. If that means that we have guidelines that lead to clear accessibility outcomes along with standards that are more geared to creating a strong accessibility program (which can go hand-in-hand), that’s something I’d support. An accessibility statement could detail how an organization is structuring their accessibility program, what protocols they’re using and how they’re ensuring accessibility. If their website is, in fact, accessible, than that would be a great addition.

But it looks like we might be saying similar and complementary things. From reading everyone’s responses, it sounds like we’re all saying that:

  1.  Organizations would still be accountable for measurable outcomes (that can be checked with an automated tool or manually)
  2.  Outcomes may have varying degrees of measurability (I really liked your matrix<>, Rachael)
  3.  For the least measurable outcomes, organizations may have to look to outside guidance (protocols) to develop processes that can help them create accessible outcomes. John mentioned (and please correct me if I don’t have this right) that this would help augment WCAG 3.0 normative language by providing a degree of definition that would allow multiple people to come to a similar determination about how well an outcome was met.
  4.  Jake mentioned that Protocols also go hand-in-hand with the maturity model work and can be used to help show an organizations progress towards accessibility by adopting a more robust accessibility program.
  5.  Jennifer seemed to agree with #3 (Jennifer please let me know if that’s not correct)

If what I have above is correct, than that might mean:

  1.  Protocols are meant to help augment subjective outcomes that can’t be measured with methods (either automated or manual checks)
  2.  Protocols that are intended to define subjective outcomes should be specific enough that reasonable people can agree that the process has been followed and the result meets the intention of the protocol – though I imagine it won’t always be 100 percent perfect.
  3.  It may help if we defined which outcomes protocols apply to (which outcomes are so subjective that we’d need a protocol to define them). That might help us select appropriate protocols.
  4.  Protocols can also be used in some cases to show that the organization has a robust accessibility program.
     *   Maybe we separate these protocols from the protocols related to requirements? I find this a bit confusing myself.

Please let me know your thoughts. Thank you.

Jaunita George, JD, PMP, WAS (she/her)
QA-ADA Analyst III, Product Engineering & Delivery Services (ISD)
DHS Certified Trusted Tester (TTV5)
[IAAP WAS circular badge and horizontal name logo for International Association of Accessibility Professionals (IAAP) Web Accessibility Specialist (WAS) credential. To the left is a dark blue circle with three lines of centered white text that read: IAAP Certified WAS. There is a smaller light blue circle that surrounds the dark blue inner circle that designates the WAS credential color scheme. To the right, two lines of dark blue text. Top text reads Web Accessibility Specialist, second line reads International Association of Accessibility Professionals.]<>
Navy Federal Credit Union, 820 Follin Lane, Vienna VA 22180
W: 571-391-0356 | C: 206-778-1882

[Navy Federal Credit Union. Our members are the mission.]

From: jake abma <>
Sent: Monday, March 7, 2022 3:42 AM
To: Alastair Campbell <>
Subject: Re: [External] Re: [Protocols] Minutes for March 4th, 2022

Het Alastair,

I agree with what you say but I think the angle of approach for the examples was a bit different.
The conversation is about (and I guess we all already know about it, but just for clearance):

  *   'what is a protocol'
  *   'what do we count as a protocol' (for WCAG 3)
  *   'will it be a fixed set' (provided by W3C?)
  *   'will it be an W3C guidance doc only set'
  *   'will it be left open, pick-and-choose your own'
  *   'how to measure' (reliable? consistent? valide? etc)
  *   'is a protocol only 'subjective' or may it also be 'objective' (and thus become 'regular outcome/method? If not directly maybe at a later date?)
  *   etc.
So my examples were a reaction also to what John Foliot mentioned about "assertions" and being accountable for your assertion.
This is very well related to maturity and its approach, and this is what triggered John in the first place to come up with protocols.
Protocols are by definition a subset of a maturity model and can be 'protocols for specific requirements' or 'protocols for how you organize your processes and behaviour'. (I think there will also be the gray area to be found in both protocol documents)

For us to choose 'protocols for specific requirements' is fine, but measuring / evaluating either one will probably contain an 'assertion' flavor, and you will need to be accountable for that part (similar to the examples I gave, its like "concrete improvement measures")

So for me it seems like we have 3 buckets that help organizations create inclusive and accessible products with their related ways of usage.

Bucket 1
"old school' guidelines (SC, Outcomes, Methods)
=> mostly objective in nature with maybe some adjectival rating on top if we can figure out how.
=> PASS / FAIL system
=> (some subjectivity will always be present but kept to a minimum)

Bucket 2
'Protocol guidance' (for specific requirements as you mention)
=> mostly subjective in nature where assertions need to be made (like "concrete improvement measures")
=> JUDGEMENT CALL made on provided statements / assertions, with dates, effort, and (subjective)results (?!)
=> (some objectivity can always be presented but often takes lots of evaluation like surveys, (user) tests, manual checks, etc.)

Bucket 3
'Maturity Evaluation'
=> mostly subjective in nature where assertions need to be made (like "concrete improvement measures")
=> Judgement call made on provided statements
=> (objectivity can always be presented but often takes lots of evaluation like surveys, (user) tests, manual checks)

And so, being accountable for your own statement / assertion  / concrete improvement measures works, also from a legislative perspective.
This is not only 'our' experience here in The Netherlands (and other EU countries going into this direction) but also in the USA, where Governance is included in settlements... see for example slide 8:<>

Governance included in settlements:
HR Block & PeaPod

  *   Appoint a skilled web accessibility coordinator who will report directly to an executive
  *   Adopt a web accessibility policy
  *   Mandatory accessibility training for web content personnel
Youngstown State University & University of Montana

  *   Develop web accessibility policy and an implementation and remediation plan
  *   Mandatory accessibility training for web content personnel
  *   Put in place mechanisms to ensure that the sites continue to be accessible.
So the subjectiveness of a Protocols seems to fit in between old school Guidelines and Maturity Model Proof Points and might be a suitable option also from a legislative perspective.

Hence the given example...


Op zo 6 mrt. 2022 om 21:32 schreef Alastair Campbell <<>>:
Hi Jake,

Would it be fair to say that the approach in the Netherlands you outlined is for the site/organisation?

Just from the outline, e.g:
"agency has appointed concrete improvement measures"

To me, that is more about the scoring, or possibly the aggregation level, which we aren’t tackling yet (or perhaps that’s best left to regulators).

As Rachael outlined, we’re currently tackling the ‘protocols’ for specific requirements (e.g. plain language), which is a different thing. The language here is new (to most of us) and overlapping, let’s all try to keep these things separate.

Kind regards,



@alastc /<>

Received on Monday, 7 March 2022 16:15:02 UTC