Re: [Protocols] After today's call

Just an idea taken from an ISO to conform to 'subjective' (?) efforts of
following a guidance document:

Conformity
If an organization claims conformity with a protocol document, then the
decisions about how it addresses the requirements and recommendations in
this document or the justifications for any course of action that deviates
from any of the recommendations shall be documented.

Documentation of a claim of conformity with this document should be
specific about the basis on which the claim is made and should provide
evidence to support the claim. An organization can claim conformity on the
basis of a self-assessment or an assessment carried out by another party.

*Checklists for ISO/IEC*

This annex provides an example of checklists (see Table F.1 and Table F.2)
that can be used to determine whether the requirements and applicable
recommendations in this document have been met. Use of these tables is not
a substitute for understanding and using the entire document.

The tables contain all recommendations from this document, presented in
sequence.

— Table F.1 focuses on embedding ICT accessibility within an organization.

— Table F.2 focuses on embedding ICT accessibility within an ICT system.

Each table contains the following columns:

— Column with pre-entered information based on this document;

1) Identification information;

a) structural entries in the table (clauses/subclauses, which are only for
the informative purpose of identifying the location in which guidance
appears) are identified with:

i) their clause/subclause number;

ii) title;

iii) the entire row being shaded grey indicating that they are not directly
complied with;

b) requirements entries in the table are identified with:

i) their clause/subclause number and, where multiple requirements and
recommendations in a subclause, further information such as list item
number [e.g. "a) 1)" for sub-item 1 within item a of a list] or the number
of the paragraph (e.g. p3 for the third paragraph in the clause) and
sentence within paragraph (e.g. s2 for the second sentence in the
paragraph);

ii) an abbreviated summary of the requirement1);

iii) the word "REQUIRED:" placed at the start of column 3, indicting the
need to have met the requirement in order to comply with ISO/IEC 30071-1;

c) recommendation entries in the table are identified with:

i) their clause/subclause number and, where multiple requirements and
recommendations in a subclause, further information such as list item
number [e.g. "a) 1)" for sub-item 1 within item a of a list] or the number
of the paragraph (e.g. p3 for the third paragraph in the clause) and
sentence within paragraph (e.g. s2 for the second sentence in the
paragraph);

1) These abbreviated summaries of the requirement are not intended to
replace the full wording of the guidance in the normative portion of this
document. They are only abbreviated to support quick recognition when using
this checklist with the complete document.


ii) an abbreviated summary of the recommendation2);

iii) the entire row being shaded grey where compliance with a
recommendation is based on compliance with more detailed recommendations
that are included in the table (and referenced in column 3);

— Columns intended to be filled out for the organization/system being
reported on:

2) Whether or not the guidance

a) has been followed (Yes/No) in rows involving compliance answers; or

b) is dealt with by other recommendations (prefilled as "---");

3) An explanation of whether or not complied with;

a) if based on more detailed recommendations, then a pre-entered reference
to those recommendations;

b) if complied with, then a brief statement as to how the guidance has been
followed;

c) if not complied with, then the justification for why the guidance has
not been followed.

2) These abbreviated summaries of the recommendation are not intended to
replace the full wording of the guidance in the main document. They are
only abbreviated to support quick recognition when using this checklist
with the complete document.

Op vr 11 mrt. 2022 om 20:28 schreef John Foliot <john@foliot.ca>:

> Hello All,
>
> Thank you for posting today's minutes. This email provides my comments on
> four different topics raised on today's call:
>
>    1. Defining "Protocols"
>    2. Scoring Protocols (credit)
>    3. Statements versus Assertions
>    4. Protocols in the Regulatory environment
>
> *********************************************
>
> *Defining "Protocols"*
>
> shadi: shouldn't spend to much time trying to define what it is, but in
> terms of communication, every time I hear protocols described, its a
> different description. It makes it hard for somebody to be involved and
> help.
>
>
> I agree with Shadi - words are important and so are definitions. I don't
> think that definitions within this group need to be "normative" at this
> time (but perhaps down the road?), but having a shared understanding of
> what is meant by a Protocol is - to my mind - a critical point. Since the
> group has been using some examples to help flesh out the larger
> conversation, I'd like to suggest that there are two examples that seem to
> have a similar structure, that also meet my mental model:
> plainlanguage.gov's Requirements, and Making Content Usable For...COGA's
> Outcomes. Based on those two documents (and some word choices previously
> provided by Juanita), might I suggest the following definition:
>
>
>    - A Protocol defines outcomes that cannot be specifically measured.
>    Outcomes impacted by Protocols can nonetheless be Assessed and, based on
>    the language of the Protocol, a final Determination can be arrived at with
>    some level of consistency.
>    (**IMPORTANT* there is a critical if nuanced difference between
>    "measuring" and "assessing for determination", and moving forward we should
>    be very mindful NOT to introduce the term "measure" in any of our
>    documentation*)
>    - Protocols are assessed at the 'site' or application level (i.e.
>    across multiple screens or views). Protocols are therefore holistic in
>    nature: they are generally not applied to specific or individual content,
>    but rather are a process or methodology used at content creation time.
>    (e.g.: a Plain Language Protocol is not used to assess individual sentences
>    or paragraphs, but rather applied to all written content on the
>    site/application)
>    - A Protocol provides sufficient examples and other instructional
>    content (Personas?) that evaluators can use to Assess content and other
>    deliverables covered by the topic of the Protocol; both at content creation
>    time, but also later at Determination time.
>    (A roadmap versus a yardstick.)
>    - Protocols have a high component of *education* associated with the
>    Protocol - they are instructional in their presentation, and seek to
>    'teach' content creators how to achieve a successful outcome.
>
>
> *********************************************
>
> *Scoring "Protocols" (credit)*
>
> <jaunita_george> I'd feel more comfortable if it's more "extra credit" or
> related to the maturity model work.
>
>
> This aligns with my thinking as well. We are stuck in that currently the
> scoring and conformance work within our group is stalled, but broadly
> speaking the *thing* that will differentiate Gold from Silver and Bronze is
> (conceptually) "*points*" (i.e. a final score).
>
> In my original presentation, I had suggested that the application of
> Protocols would accrue *points *that would contribute to the 'final
> score'. However it's not *"extra credit"*, it is simply "credit" - the
> application of Protocols should not be "extra", but rather part of a larger
> production process, and no more or less important than the application of
> specific Requirements (SC). Making them "extra" will likely have the
> unintended consequence of relegating them to the same conceptual pile as
> WCAG 2.x AAA requirements: important in context but rarely looked at or
> taken seriously. I would also strongly object to any mechanism that only
> saw Protocols "kick-in" at the Silver or Gold levels - this too will
> suggest a different level of importance, which I will argue is
> counter-productive to the larger goal.
>
> *********************************************
> *Statements versus Assertions*
>
> CA: speaking about ways of how a protocol was done
> … sometimes we talk about a public statement
> … but I don't know what a public assertion is
>
>
> I have noted that words are important, and this remains true here too. To
> my thinking, a Public Statement or a Public Assertion are essentially the
> same thing: it is a *public* and binding statement of fact made by the
> entity. *Plain language principles* would lean towards calling it a
> "Statement", however the nuanced but real difference between the two
> dictionary definitions of those terms continues to lead me to favor
> "Assertion". Merriam Webster says:
>
> Definition of *statement*
>
> 1: something stated <https://www.merriam-webster.com/dictionary/stated>:
> such as
>
>           a: a single declaration or remark
>           b: a report of facts or opinions
>
> Definition of *assertion*
>
>     the act of asserting
> <https://www.merriam-webster.com/dictionary/assert> or something that is
> asserted: such as
> a: *insistent and positive affirming, maintaining, or defending* (as of a
> right or attribute)
> an assertion of ownership/innocence
> b: a declaration that something is the case
> He presented no evidence to support his assertions.
>
> In this context it outlines a promised commitment, and based on the
> example I shared previously (and, I suspect, in alignment with similar
> documents that Jake has referenced previously) could mandate - in our
> context - some specific requirements (date, duration of the statement - we
> could limit it to 12 or 24 months for example, the *public URL* where
> anyone can go and read the "expected outcomes", the name of someone within
> the organization who has taken the formal responsibility for ensuring the
> Protocol statement is written, updated, and most importantly applied, etc.)
>
> *********************************************
> *Protocols in the Regulatory environment*
>
> JG: not sure how much we should tie this to courts
>
> Two thoughts here:
> 1 - we do not do the "tying", that is up to the regulators. We produce
> Recommendations (Standards) that the regulators incorporate into their
> legislation. We have multiple examples today where legislators have adopted
> WCAG 2.x with specific modifications or omissions. (ref: AODA
> <https://www.aoda.ca/new-aoda-requirement-for-ontario-websites/>)
> 2 - looking at Plain Language, and plainlanguage.gov - it appears that
> the US Federal Government has already adopted the broader concept of a
> "Protocol" [sic] and have provided a conformance and compliance reporting
> mechanism already, so I do not think this will be novel nor controversial
> to the regulators - it is in fact building on a pattern they first
> established more than a decade ago (at least in the US - we need to also
> remember that our Recommendation needs to work at a Global level as well)
>
>
> JF
> --
> *John Foliot* |
> Senior Industry Specialist, Digital Accessibility |
> W3C Accessibility Standards Contributor |
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>