W3C home > Mailing lists > Public > public-silver@w3.org > October 2021

[Maturity] Minutes from Maturity TPAC Breakout

From: Sajka, Janina [C] <sajkaj@amazon.com>
Date: Fri, 22 Oct 2021 15:18:47 +0000
To: "public-silver@w3.org" <public-silver@w3.org>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Message-ID: <dac3189dfc6245f3a11ea12a980e0b0d@EX13D28UWC001.ant.amazon.com>

Minutes from the Silver Maturity Model TPAC Breakout teleconference of
Friday 22 October 2021 are provided here.

===========================================================
SUMMARY:
Introduced current state of work on a possible model:
*            Applies to any size organization from sole proprietor to
              mega-corporation; NGO, or governmental entity;
*            Intended to help measure and document improvement over time
*            Provides mechanisms to measure and document nontechnical aspects of
              maintaining a11y over time, e.g. procurement
===========================================================

Hypertext minutes available at:
https://www.w3.org/2021/10/22-silver-maturity-minutes.html


===========================================================

   W3C

                                                                                                            - DRAFT -
                                                                                                 Silver Maturity Model Breakout

22 Oct 2021

Attendees

   Present
          atai, Ben, bkardell_, cel, Fazio, JakeAbma, jasonjgw, Jaunita_George, JF, Joshue108, KimD, kirkwood, maryjom, MichaelC, MURATA, plh, Raph_, rickj, Roy, sajkaj, SamKanta, shadi, Sheri_B-H, stevelee,
          SuzanneTaylor, ToddLibby, tzviya, Wilco

   Regrets
          -

   Chair
          Fazio, SBH

   Scribe
          sajkaj

Contents

Meeting minutes

   <Fazio> Maturity Model Slide Deck https://docs.google.com/presentation/d/1ATkbsN04HZE_L-PGH8ZKtWWiGl-stTze/edit#slide=id.p1

   df: Introduces concept of adding a maturity model to Silver, and its potential value in WCAG3 documenting, and next step decisioning

   df: Very much like ISO9000 series of specs: "Say what you mean, and do what you say"

   <jeanne> slides

   df: What to do, when, and how--how to hold feet to the fire

   df: Introduces subgroup participants ...

   Sheri_B-H: these are tools for assessing effectiveness

   Sheri_B-H: a continuous improvement loop

   Sheri_B-H: phps quickly, phps annually, but keep looping

   Sheri_B-H: idea is that it's an addon, not a replacement

   <jeff_> Present

   Sheri_B-H: written so as to not depend on a particular WCAG version

   Sheri_B-H: covering anything that could impact a11y

   Sheri_B-H: set a goal for maturity level, then figure out what needs to change to achieve that level

   Sheri_B-H: model intended to scale from 1 person shop through mega-corporate; commercial, ngo, or governmental

   Sheri_B-H: allows localization, e.g. no presence in California, can keep that part out

   Sheri_B-H: i.e. not every proof point applies to everyone

   raph: shows example of current best practice

   Raph_: shows deviations to wcag; but also nontechnical barriers

   Raph_: what is suggested is a slightly different approach

   df: Provides audio description of the slide ...

   Sheri_B-H: notes it's the standard reactive response; find challenges through testing, fix, test again

   <Raph_> Figure containing a model view of the currently usual ict accessibility approach, based on the outcome of WCAG conformance testing The starting point is (a policy containing) an accessibility goal. The goal
   applies to an ICT object. The accessibility of the ICT object is compromised by two types of barriers: technical and non technical. The technical barriers can be found and dealt with by testing the ICT object for
   conformance, using WCAG.[CUT]

   <Raph_> Figure containing a model view of the currently usual ict accessibility approach, based on the outcome of WCAG conformance testing

   <Raph_> The starting point is (a policy containing) an accessibility goal. The goal applies to an ICT object.

   <Raph_> The accessibility of the ICT object is compromised by two types of barriers: technical and non technical.

   <Raph_> The technical barriers can be found and dealt with by testing the ICT object for conformance, using WCAG.

   <Raph_> The WCAG test results provide input for evaluating goal achievement (= plan-do-check-act cycle #1).

   df: Again describes ...

   <Raph_> In this model, non technical barriers remain out of scope.

   <Raph_> Examples of non technical barriers are: procurement, path dependence, knowledge, skills, tools, prioritization, budget, the cost of change, organizational complexity, 3rd party dependence, contracts, the
   organization's culture etc.

   Raph_: idea is that nontech barriers can affect a11y level--even so as to keep the challenge from being recognized

   Raph_: Derived from a 1970s study ...

   Raph_: notes it includes the organizationan component

   Raph_: Responding to q for nontech example--Procurement

   Raph_: another is organizational complexity

   <Raph_> Figure containing a model view of a more comprehensive ict accessibility approach, based on taking organizational improvement measures

   Raph_: these have nothing to do with wcag, but influence ability to conform

   <Raph_> The starting point is (a policy containing) an accessibility goal.

   <Raph_> The goal leads to organizational improvement measures, utilizing a maturity model. The improvement measures apply to an ICT object.

   <Raph_> The accessibility of the ICT object is compromised by two types of barriers: technical and non technical.

   <Raph_> The technical barriers can be found and dealt with by testing the ICT object for conformance, using WCAG.

   <Raph_> The WCAG test results provide input for new improvement measures (= plan-do-check-act cycle #1).

   <Raph_> Examples of non technical barriers are: procurement, path dependence, knowledge, skills, tools, prioritization, budget, the cost of change, organizational complexity, 3rd party dependence, contracts, the
   organization's culture etc.

   <Raph_> The non technical barriers provide input for new improvement measures (= plan-do-check-act cycle #2).

   <Raph_> The improvement measures provide input for evaluating goal achievement (= plan-do-check-act cycle #3).

   <Raph_> Note: The primary indicator for an organization's maturity regarding ICT accessibility should not be the level of conformance to WCAG of its ICT, but the performance of the organization in making its ICT
   (more) accessible.

   <Raph_> PS: All elements of the previous figure (on slide 6) are present in this figure

   Sheri_B-H: have defined 4 different maturity stages

   Sheri_B-H: most models have a fixed number; we decided on 4

   Sheri_B-H: first is completely inactive

   Sheri_B-H: next is start

   Sheri_B-H: third is more integration

   Sheri_B-H: top is release to release integrated--a model for others to copy

   Sheri_B-H: in these we have 7 different dimensions

   sajkaj: Wow, for the first time ever, Zoom is reading slide content via Zoom!

   Sheri_B-H: Notes she used modeling at several positions starting with role at SSB

   Sheri_B-H: has been helpful in several corporate implementations

   Raph_: one of the bigger problems in governmental was partial/incomplete a11y, therefore could not meet wcag

   Raph_: so, improvement--but we needed better measurement to account for progress than wcag 2.x binary

   Raph_: model gives us a better view than available previously

   Raph_: we don't yet have a formal model, which is why I'm in the group

   Raph_: we're getting there

   Sheri_B-H: notes that vpat or audit does not help with indicators for maintainability

   Sheri_B-H: you get to a point, but can you keep it up?

   Sheri_B-H: Notes value in her corporate environment for maintanance

   Jeff_Kline: notes value add over vpat

   Fazio: will companies do this?

   Fazio: actually, yes. notes adoption of iso9000 series; it's cost effective to do this

   Fazio: moving now to outcomes in the model ----

   Sheri_B-H: using many of the same definitions currently modeled in silver

   Sheri_B-H: e.g. outcomes

   Fazio: notes outcomes is in this model thanks to work on functional needs

   Sheri_B-H: notes the need to show and evaluate every level and each dimension -- proof points which are customizable based on business need

   Sheri_B-H: goes through an example

   Fazio: notes names of elements in the model are provisional, may change!

   Sheri_B-H: e.g. the U.S. Trusted Tester may not require same training as another testor in another org

   Jeff_Kline: now an example in procurement

   Jeff_Kline: notes standard phases of procurement and where/how a11y is factored into those

   Jeff_Kline: continuing into life-cycle management

   Jeff_Kline: a11y reqs are communicated to vendors because identified as a todo in this model

   sajkaj: as your scribe, not sure how to disambiguate--do we have two "Jeff" nics on channel?

   Jeff_Kline: notes some needed expertise that may be needed; a11y capable procurement officer; eval, etc

   Fazio: purposefully set this apart from numerical scoring

   Jeff_Kline: no definitive lines between stages, things may be fluid

   Jeff_Kline: it's a guage

   <jcraig> sajkaj the substitution works.. we can fix it in the minutes at the end, unless the real Jeff has something to say this meeting

   <Zakim> sajkaj, you wanted to ask about defect rates

   <Joshue108> JS: You were talking about metrics

   <Joshue108> One jumped out, related to defect rates and how to quantify

   <Joshue108> Using the principle that all software has bugs..

   <Joshue108> Any related study, that aims to define this would be useful in the Silver process

   <Joshue108> I understand how a radical change is radical

   <Joshue108> Just to flag this..

   sajkaj: notes "acceptable defect level" is a concept we weren't able to define when we tried to address

   Jeff_Kline: notes defects is a difficult area; in procurement might be a contractual term to show continuous improvement

   Jeff_Kline: or phps error rates of X% in Y years

   Jeff_Kline: point of proof points is that they need to be demonstrable--so three subheadings under procurement

   Jeff_Kline: includes communicating expectations to vendors and use of consistent contract language

   Jeff_Kline: consistent forms

   Jeff_Kline: regular documented eval that is retained

   Jeff_Kline: /ginotes example of how organized--a template spread sheet

   Fazio: describes slide

   <cel> WCAG Maturity Model Procurement Dimension Worksheet https://docs.google.com/spreadsheets/d/1fzPlHjHIaSQn9GvpJd86SDpV49U8Beg_iXj6K5aeyGg/edit

   OK: I'll switch to using jk

   Fazio: opens to questions

   jk: Notes some on call more familiar with maturity, but others more on technical side

   jk: think of maturity as an eabler by putting required pieces in place to make the organization more effective overall

   Fazio: notes involving pwd in process in order to know; testing with pwd is important

   Jeff_Kline: /ginotes a range of staffing skills where a11y knowledge needs integration; not just technical devs

   Richard_Morton: slide 6 seems skype example

   Sheri_B-H: that's a before and after slide

   <Zakim> Richard_Morton, you wanted to jeff_k, why does slide 6 says non-technical barriers remain out of scope? It appears that everything is in scope.

   jk: intended to show nontechnical dimensions that matter

   jf: voices concern that scope of applicability

   jf: wants to emphasize wide applicability

   Sheri_B-H: not all proof points are applicable; but the model can be applied across organizational size

   Sheri_B-H: we don't want to force small organizations to measure and respond on reqs that don't apply to them

   jk: idea is to facilitate scaling

   jk: 2 person small business; some items may not apply

   jf: who makes the decision? and how does that integrate and standardize into reporting?

   jf: who defines?

   jk: we can certainly come up with general guidance

   Sheri_B-H: report produced would include what was, and what wasn't measured

   Sheri_B-H: the model is as good as the people doing the measurement and disclosure

   Jeff_Kline: /ginotes this isn't a conformance model; more a workplan

   Sheri_B-H: Invites people to participate

   Sheri_B-H: Wednesday 8:00 AM Pacific meeting time

   Sheri_B-H: invites participants

   stevelee: stevelee: notes these are measurements for the organization; and not a conformance model

   <Fazio> dfazio@helixopp.com sbyrnehaber@vmware.com

   <Zakim> JF, you wanted to respond

   jf: fully on board with the concept; but doesn't understand how to integrate into the model

   Sheri_B-H: we're not to that point yet

   Sheri_B-H: we've not gotten to integration; and integration isn't even necessarily required

   Sheri_B-H: reminds she noted up top the model is intentionally wcag version agnostic

   bkardell_: asks who's the audience for this model?

   jk: any private or public sector org of any size

   Fazio: notes common question following presentation is: "how do i start?"

   Fazio: this model provides a path

   Raph_: notes NL published booklet on that and will share

   <Raph_> Web accessibility in your organisation: roles and responsibilities

   <Fazio> https://www.digitoegankelijk.nl/sites/default/files/2021-03/Web%20accessibility%20in%20your%20organisation.pdf


    Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).


   Maybe present: df, Jeff_Kline, jk, OK, raph, Richard_Morton


----------------------------------

Janina Sajka
Accessibility Standards Consultant
sajkaj@amazon.com<mailto:sajkaj@amazon.com>
Received on Friday, 22 October 2021 15:19:06 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:54 UTC