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:
https://mn.gov/mnit/assets/Policy%20Driven%20Adoption%20for%20Accessibility%20%28PDAA%29%20CSUN-Public_tcm38-61817.pdf

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...

Cheers!

Op zo 6 mrt. 2022 om 21:32 schreef Alastair Campbell <acampbell@nomensa.com
>:

> 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,
>
>
>
> -Alastair
>
>
>
> --
>
>
>
> @alastc / www.nomensa.com
>
>
>
>
>