Meeting minutes
<gb> /issues/148 -> #148
<gb> /issues/157 -> #157
<gb> /issues/226 -> #226
<gb> /issues/137 -> #137
New Business
<stacey> Can someone send the right link for the call? I keep connecting, but I'm the only one on Zoom.
<Fazio> emailed your gmail
<stacey> TY!
Use Cases Update
Sheri_B-H: procurement for a multi-org.
… We can email this for review its a page.
… I will email it out. Jeff looking for your comments.
… in reviewing other use-cases we can modify some of the older ones. Will open up a ticket for that.
… updates are not big.
David: down to 15 issues.
jkline: wondering with use cases if its necessary to put in the roles all the time? seems may not be necessary.
David: maybe ask Stacey. usability review?
Sheri_B-H: we discussed this Jake pushed hard to have a stake holder list. ie who to involve. We don't discuss this at all. I think we need to leave them in maybe condense them.
David: Stacey if you can review that section.
stacey: it is quite big and could be condensed.
Sheri_B-H: maybe you and I can review together Stacey.
stacey: Sure.
David: this is more editorial I would say. do we need a issue for this?
janina: if its useful to track progress, it doesn't matter.
Sheri_B-H: 1-2 weeks tops we should have this done. agreed by Stacey.
CharlesL: we don't have to have every github issue resolved before we move to a release.
Scoring Spreadsheet Instructions Follow Up
jkline: Yes I have added this, revised by Charles and Mark. there is now an instruction page in the excel spreadsheet.
David, Do we need to add it to the document?
jkline: I don't think we do. could add to an appendix. but I don't think we need it.
CharlesL: this is done and we don't need add instructions to the document. only in the excel spreadsheet.
Github Issue #148 Add information fields for metadata for each dimension
<gb> /issues/148 -> #148
<Fazio> achttps://
Add information fields for metadata for each dimension #148
David: Add fields for each dimension that provides information such as (but not limited to: name of completer of the dimension form, Functional area(s) encompassed, scope of the organization included, etc
jkline: this tool may be sent to multiple departments / divisions it would be useful to add these fields?
… if we add the fields to the top.
Charles: we do have "Assessment Scope" field at the top of each dimension already.
jkline: it is also good to have a name associated for traceability.
… we don't know how long this version of the spreadsheet will be out there, open schedule on when this gets converted.
… if there are enhancements we should do that. it will be easier to do now.
David: should we do it?
jkline: I will do it.
David: jeff will add metadata to the spreadsheet.
Charles: Jeff please just send me the list of metadata to include.
Github Issue #157 Section 3.6: proof points should be expanded to take into account evidence of the outcomes of the procurement process.
<gb> /issues/157 -> #157
Section 3.6: proof points should be expanded to take into account evidence of the outcomes of the procurement process.
Section 3.6: proof points should be expanded to take into account evidence of the outcomes of the procurement process. · Issue #157 · w3c/maturity-model
<Fazio> w3c/
<gb> Issue 157 Section 3.6: proof points should be expanded to take into account evidence of the outcomes of the procurement process. (by jasonjgw)
David: asking us to define metrics and goals of the procurement process.
jkline: yes we did
Sheri_B-H: its not always possible to procure an accessible product. so I don't know calculating what you were doing before / after.
… I don't think its a good measure.
David: he is looking at the ISO standard which is complementary to our maturity model.
… I believe the ISO standard does have something for procurement.
jkline: I think we have this in the new proof point we added. "how many procurements % of, that are demonstrated to be accessible, % of a11y mentioned in SOW and contracts. he is providing examples but may not be the best examples for our model.
David: We feel we have addressed this issue and will close it with comments.
jkline: we should address the 3 specific points he pointed out.
… without being specific for the goals / metrics...
David: word smithing the response before closing the issue.
<Fazio> suggested resolution: Without requiring specific metrics and goals, we believe that our addition of metrics and goals resolves this issue, to the extent applicable by the maturity model.
Github Issue #226 Add an explanatory section on dimension goals and metrics
<gb> /issues/226 -> #226
Add an explanatory section on dimension goals and metrics
<gb> Issue 226 Add an explanatory section on dimension goals and metrics (by jasonjgw)
David: we added metrics and goals, for each dimension but he is looking for examples.
stacey: holistically an organization may not know how to create a metrics and goals. I think it is important but it is subjective to their business / needs.
jkline: This is project management 101 defining some goals. you can make the same argument for a lot of the proof points.
… there may be some in my book, if someone doesn't understand how to define goals for a project, doesn't need to be specific to accessibility...
stacey: have to assume they don't have a11y knowledge.
… I do product management but when you add in a11y they are blanking on what they need to do next.
David: I think Stacey's approach works here. very generic but useful.
<janina> +1 to Pre-Requisites; Could be called "Assumptions"
Sheri_B-H: slightly different: a "prerequisite" section skills of what this section needs.
David: suggested skill sets. contract with someone who has this skill set if you don't have it yourself.
… can you take a crack at that Sheri?
Sheri_B-H: I can take a crack but where would this go?
… we can talk about this at the same time with Stacey. In the abstract section. set expectations.
jkline: section 1.2 Audience for Maturity model.
Sheri_B-H: maybe add more on skills. suggested skills
jkline: an executive in charge of this would go find those skills needed
stacey: maybe hire someone, like PDF remediation for example :)
David: Jason says its not clear. that Table. clarify things and things to consider, skills needed etc.
jkline: who can help us define these goals, this is a progressive model.
David: we have a couple places for this and will point Jason to this once Stacey and Sheri update the document.
Github Issue #137 Address the accessibility of entire processes in the Maturity Model.
<gb> /issues/137 -> #137
Address the accessibility of entire processes in the Maturity Model
<gb> Issue 137 Address the accessibility of entire processes in the Maturity Model. (by jasonjgw)
stacey: the maturity model is digital spaces not physical spaces.
jkline: This is no in scope, compliance issue, no proof points to try and deal with this. we are trying to enable an organization...
janina: out of scope
Sheri_B-H: this is the opportunity can extend the model to include these other ideas.
janina: we are about documenting.
Sheri_B-H: we aren't signaling out him just other groups are doing this and can extend where appropriate.
David: yes we won't address this and just say out of scope.