Meeting minutes
<Fazio> Maturity Model Slide Deck https://
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://
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