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

Hi Juanita,

Comments in-line:

> *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) *
   JF: that was effectively what *I* was proposing for Protocols, yes.

   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. *
   JF: Agreed. In fact, I personally do not expect experts to agree on
   specifics, ever. However, as long as both experts and non-experts (like the
   judge) can agree broadly, we've (I will argue) succeeded. Again, using the
   Text Alternative example: you and I will likely never be in 100%
   synchronization with regards to specific text alts authored for any given
   image, but you and I (as SMEs) would likely be very close most of the time
   - and if we both used the same Protocol when writing our text alternatives,
   I would hope that the gap between your subjective choice of text versus my
   subjective choice of text will be small - and smaller than if we weren't
   using the same protocol.

   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. *
   JF: Agreed in principle, although I think some of that work has happened
   already. Take for example "Making Content...COGA", which has already
   defined 8 "impossible to measure but needed anyway" requirements:

   1. Help Users Understand What Things are and How to Use Them
      2. Help Users Find What They Need
      3. Use Clear and Understandable Content
      4. Help Users Avoid Mistakes and Know How to Correct Them
      5. Help Users Focus
      6. Ensure Processes Do Not Rely on Memory
      7. Provide Help and Support
      8. Support Adaptation and Personalization

   The US plainlanguage.gov site also has 8 identified 'Outcomes' that
   again are very hard to precisely measure but are important to deliver-on;
   in fact both documents have a very similar structure which we may
   potentially learn from (and "borrow"):

   1. Write for your audience
      2. Organize the information
      3. Choose your words carefully
      4. Be concise
      5. Keep it conversational
      6. Design for reading
      7. Follow web standards
      8. Test your assumptions

      4.
*Protocols can also be used in some cases to show that the organization has
   a robust accessibility program. *
      1.

*Maybe we separate these protocols from the protocols related to
      requirements? I find this a bit confusing myself. *

JF: this is where I think we are in some partial disagreement. I am
proposing/suggesting that adopting Protocols as components of WCAG 3 is
*PART* of a robust accessibility program - especially IF part of meeting or
adhering to the Protocol involves accessibility program-like activities.
So, for example, when I proposed a strawman 'conformance report' last week,
I noted that part of the statement (regarding plain language) was, in my
example, a statement related to training. Whether that becomes a
requirement for ALL Protocols is a TBD in my mind, and a detail worth
discussing more.
But in my current thinking, Protocols are a bit more specific than "a
Program", as they will directly track back to *content authored/created*.
(ref: "Making Content...GOGA", "Plain Language", perhaps "Alt Decision
Tree", etc.) And additionally (although we've not yet discussed this part),
I had envisioned adopting Protocols as contributing to the final overall
score that maps to Bronze, Silver or Gold: that adopting Protocols also
accrues the content owner/creator "points". If we want to make a Protocol
that broadly defines what an Accessibility Program is (or looks like), then
sure, that MAY become a Protocol that could accrue points, but I'm
currently leaning towards "An Accessibility Program **supports** an
organization in delivering on one or more Protocols".

Does that make sense?

JF


On Mon, Mar 7, 2022 at 11:14 AM Jaunita George <
jaunita_george@navyfederal.org> wrote:

> 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:
> https://news.mobar.org/confronting-the-rise-in-ada-website-accessibility-lawsuits-against-businesses/
> and
> https://www.americanbar.org/groups/law_practice/publications/law_practice_magazine/2022/jf22/vu-launey-egan/.
> 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:
> https://www.essentialaccessibility.com/blog/biden-effect-doj-digital-accessibility
> and
> https://www.jdsupra.com/legalnews/recent-doj-settlements-show-step-up-in-8723386/#:~:text=Web%20Accessibility%20Enforcement%20by%20the%20DOJ&text=The%20DOJ%20has%20authority%20to,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
>    <https://docs.google.com/presentation/d/1b5xHQWBzoYdKp7BfPgIUBCpz-yaDOx_kSq_HlQxcFh0/edit#slide=id.g115ec01aa81_0_57>,
>    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.
>       1. 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)*
>
> [image: 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.]
> <https://www.accessibilityassociation.org/s/wascertification>
>
> Navy Federal Credit Union, 820 Follin Lane, Vienna VA 22180
>
> W: 571-391-0356 | C: 206-778-1882
>
>
>
> [image: Navy Federal Credit Union. Our members are the mission.]
>
>
>
> *From:* jake abma <jake.abma@gmail.com>
> *Sent:* Monday, March 7, 2022 3:42 AM
> *To:* Alastair Campbell <acampbell@nomensa.com>
> *Cc:* public-silver@w3.org; w3c-wai-gl@w3.org
> *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:
> https://mn.gov/mnit/assets/Policy%20Driven%20Adoption%20for%20Accessibility%20%28PDAA%29%20CSUN-Public_tcm38-61817.pdf
> <https://secure-web.cisco.com/1meoeMrYcgFVV3Qco6-l3dssi2HhNkstXssd89FELxjoryfMkWueP25_bLxoA89xndjFmF3P7vCdvVNYTsAgvRqSSTgCsLbI32Dccm1LrFZRhsEELk4T-ZVxgpQi7BxM550cyvY0h3_GaapoZ5sq4JrwbT0Lz18wQlpMWc0Yd8_xrbMSwAiFX86t3S55UqDFQfgki3qdONkj8oMEa98MxM7EdlKhsfV3kXeXu6JD1t6LG4ncVC94PaDNRlIGGkgTbwyjxHo7aH5eOvXIGTr0wNB4jUJh_hV3Yqeium5d8bfquEvk20e8iiAhheoPNFQgY50GrcusqnUSX6Og3qj8NAnLreUCkCFKsYjFIsjFq0yoo1wvBi49kNNR0Ba12NGXfcYCS238pZGqO_Ch_ak2GGHj2nJ2mH_RmEWmYHfB0-jo0pj8jFZcOuwBmo7NCPBhBogcHkloHpBKqLDFYZNjyVQ/https%3A%2F%2Fmn.gov%2Fmnit%2Fassets%2FPolicy%2520Driven%2520Adoption%2520for%2520Accessibility%2520%2528PDAA%2529%2520CSUN-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
> <http://secure-web.cisco.com/14ajBUENtLnSdYoXHRjamyENwxXwaS3MWzCw9-k00y2WC_ykzN9EkoXHabiYFXm11Ar5FkViglL0EgJnjgHsVlQFChs84W7IitgkhskVUoMs6czDcKz5y5OMFfntuegEfXbt1tadN2WHAWwsgzah2LPCglPkpfITouBlYVLaB2tl_uTY4sTO7Lb8mcP5LKnzTHcw_voYC3ZOpED9bnmhdh9hfkDWUecKyEBMrucNgaSF5heo3lA16rXcR1KgfQy_rWfrP4tqDst9vKx2wP9h4BwN29bDLajLz_q-p1vdkbgT_hIxCd_GIB13GfZdnY1uHjivkcRGbGHPCXamaouwvh67jRMQePljtkI-9c7g6AR064o44KMwOUTlxEvdbKf5nJyj1h9HK-R_YeaOvVe9IKtSrhIzLPjPCDWi54cgmh9FKbtPJwloLMMKeWU3SpLy5r9_xIfeS11EgLMJYnv_Ung/http%3A%2F%2Fwww.nomensa.com>
>
>
>
>
>
>

-- 
*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"