– DRAFT –
AGWG Teleconference

AC: Anyone new?
… silence.

Presentation from Maturity Modeling https://docs.google.com/presentation/d/1ATkbsN04HZE_L-PGH8ZKtWWiGl-stTze/edit#slide=id.p1

Ac: first half of the meeting on Maturity Model

DF: I will share my screen.
… launched group year and a half ago.
… needs to be on going.
… committee includes Sheri Byrne-Haber, Jake, Jeff Kline, Lori Samuels, Raph de Rooij , and Wilco.
… previously jf and sh

<alastairc> slide 3

DF: Maturity Model is a process
… people assess the current effectiveness of a person or group and supports figuring out what capabilities they need to acquire next In order to improve their performance.
… Components include Dimensions, Outcomes, Proof Points, Scoring System.
… Organizations with mature processes can reach higher levels of accessibility compliance over time, and provides insights where accessibility requirements and not yet fully met.
… Supplementary to conformance / compliance, not alternative

Jake: Maturity Modeling diagram.
… thesis about accessibility
… Technical barriers and non-technical barriers
… second diagram. Maturity model is in the center.
… non tech barriers need to be taken into account.
… maturity model helps with non tech barriers,

DF: Scalable and Flexible is our goal.
… Must scale to most sizes, Public and Private sector. ICT products, Services, and Information. May not be fully applicable to small organizations
… Level 0 - No awareness and recognition of need for the organization

Level 1 - Recognized need organization-wide, where planning is initiated and activities present, but not well organized
… Level 2 - Roadmap in place with overall approach defined, acknowledged, and well organized for the group or organization
… Level 3 - Full insights based on assessments, consistently evaluated and implemented, across the organization

<alastairc> Slide 9

Dimensions: Communications, Knowledge and Skills, Support, Procurement, Personnel, Culture, Software Development Life Cycle.

Jake: evaluating framework.
… layered approach.

<bruce_bailey> https://www.section508.gov/manage/reporting/guidelines-program-maturity

<bruce_bailey> https://www.section508.gov/tools/playbooks/technology-accessibility-playbook-intro/play02

Jake: Outcomes are like goals.

Proof points are more of the how.
… why and how.
… Outcomes“Result of practices that reduce or eliminate barriers for inclusiveness and accessibility that organizations experience”
… Progress by levels of implementation of Proof Points
… Fully implemented training, all identified areas
… State of accessibility agenda item Supervisory Board
… All outcomes have proof points. ( Like methods)
… “Suggested evidence-based deliverables for outcomes, used to evaluate the maturity level scale”
… Dimension Outcome: Identified accessibility related skill levels and gaps
… Proof Point: Document with completed evaluation of related skill levels and gaps
… Procurement is a “Strategic process that concentrates on finding and acquiring cost-effective products required for an organization”
… all about Solicitation / sourcing activities, Response analysis and negotiations, Selection of goods and services
… Policy Documentation: Accessibility requirements communicated to vendors
… Burden of Proof: Proof of vendor testing, automated and manual
… Level 0 | No Awareness, Level 1 | Recognized need. Level 2 | Roadmap in place (Consistent ICT procurement process,). Level 3 | Fully implemented Repeatable, consistent, and measurable processes for procuring accessible ICT products, tools and services

<bruce_bailey> Compare to 0-4 levels from slide 8: Ad Hoc (1), Planned (2), Resourced (2.5), Measured (2.9) [my guess at numbers]

<Zakim> Chuck, you wanted to ask about the difference between Level 0 outcome and Level 1 outcome

Chuck: can't see anyone falling into level 0.

df: idea is being able to prove it.
… has to be a proof point.
… must have evidence.

Jake: more summarized way.

df: exploring perceptive do we want to be.

Jake: Proof Points Examples
… Policy Documentation. Published ICT Accessibility Policy . Accessibility requirements and other information communicated to vendors.
… Consistent use of Standardized Solicitation and Contract Language
… Consistent Evaluation process & methods
… we are in the process of standardizing.

DF: Maturity Model Vs. Disability Equality Index

<bruce_bailey> Was this the term: Policy Driven Accessibility Model ?

DF: our model is different.

<jon_avila> It seems like this is something IAAP could be involved in.

We are Focus on digital accessibility.
… we are focused on operational gap analysis
… AMM Dimensions: Knowledge and Skills, Personnel, Support, Procurement, ICT Development Lifecycle, Culture, Communications
… there are other Accessibility-specific maturity model.
… good idea for us to come up with a W3C model.

<mbgower> IBM has copyrighted material covering accessibility maturity models and processes. I suspect others do as well.

<Zakim> bruce_bailey, you wanted to say very compatible with what agencies are doing in U.S. Federal space

Bruce: compatable with general services.
… additional level. Resourced

DF: please help fine tune this.

<bruce_bailey> Here's the reporting questions: https://www.section508.gov/manage/reporting

<david-macdonald> which company was that?

DF: gives one example of fully implemented.

<bruce_bailey> https://www.section508.gov/manage/reporting/questions

DF: Microsoft and sales force are the examples.

Jake: value in creating a generator.
… outcomes and proof points. Could have a exercise.
… use maturity model internally and externally

<david-macdonald> 5 stages of accessibility based on the 5 stages of grief (1) anger (2) Denial (3) bargaining (4) Depression (oh man there is a lot to do) (5) Acceptance (integration)

Jake: used EU.

<Zakim> alastairc, you wanted to ask whether having an certain sized organisation is an assumption?

AC: how would it fit in with WCAG 2 and 3.
… Should it be an optional aspect?

DF: It is scalable. could be used by a person with a blog to large enterprises.

Ac: different ways to do this.

JS: don't exactly where would live in WCAG 3. Number of options.
… optional process. For people who want to go beyond Bronze.

<AWK> +AWK

Katie: Back I the day we had CPIC.

<david-macdonald> =resent+

<bruce_bailey> https://www.ocio.usda.gov/about-ocio/information-resource-management/capital-planning-and-investment-control

Katie: there are tools that companies can use.

<ChrisLoiselle> https://www.doi.gov/ocio/policy-mgmt-support/capital-planning-and-investment-control

<bruce_bailey> CPIC is not something I remember

Katie: Maturity Model can take 2 to 15 years.
… many pieces.
… a good resource for us. Maybe an EO thing.
… great tool.

<bruce_bailey> From that USDA example: CPIC is mandated by the Clinger Cohen Act of 1996 which requires federal agencies to focus on the results produced by IT investments.

Katie: not a technical thing. Can't see it as a standard.

DF: tried to make it simple.
… good marketing took.

<bruce_bailey> FWIW, Clinger-Cohen also defined IT (the term) for the Federal government, so CC is important to 508.

DF: s/took/tool/

Katie: no funding for it.

<Zakim> mbgower, you wanted to say my big concern is that I don't think this aligns sufficiently with w3c. Only section 3.4 seems highly relevant

MG: Maturity Model are great.
… vital for organizations..
… Seems like an IAAP thing.

DF: 12-24 kinds of Maturity Models.
… This is a focused one on digital accessibility.
… believe there is a place for it.

<Ryladog> true what Mike is saying IAAP they work with #GICT and United Nations

<mbgower> I think a holistic take is great. I think the approach is swell. I just question whether w3c is the place for this.

Wilco: like the idea of Maturity Model as part of WCAG.

<david-macdonald> ok back in

<alastairc> Document for comments: https://docs.google.com/document/d/1Y5EO6zkOMrbyePw5-Crq8ojmhn9OCTRQ6TlgB0cE6YE/edit#

<alastairc> Slides for viewing: https://docs.google.com/presentation/d/1ATkbsN04HZE_L-PGH8ZKtWWiGl-stTze/edit#slide=id.g7b40a70e7d_2_1

Wilco: is there a component that helps us capture how this is not currently captures in WCAG 2

DF: trying to touch those points and address those needs.
… thing we got a good start.

<Zakim> jeanne, you wanted to say Bruce's early proposal to have different currencies for scoring. Maturity model would be a different currency

Wilco: split WCAG 3 out into different parts.

JS: bruce made a proposal several years ago on different currencies with different scoring.
… lots of disagreements.
… would like to get some agreement on going forward with this doc.

<Zakim> Chuck, you wanted to queue for upcoming scribe change

<Chuck> alastair: Was it ok to record some of the content?

<mbgower> I'm having debates with people about whether _just_ documentation of dev accessibility processes (i.e. 3.4 of this doc) is overly onerous for an org to document

<Chuck> everyone: ok to have recorded.

David M: A few things. Organizations without maturity model fail to implement WCAG. Large organizations have done it well, some don't do it all all, and some just fail.
… Every org needs a maturity model. The big consulting agencies each have their own maturity model.
… Would be great if orgs could be required to have a maturity model but not sure if that's possible.
… Maybe we could pursue a model with different tracks but that would be more difficult. Can't see us having jurisdiction over non-web content.
… Discussion on Silver list last week proposed to exempt third party content from conformance statement. A company claiming conformance would have procurement built in.
… Would like to see that happen in WCAG 3

<jeanne> +1 that we are not going to require it.

David F: Is basically a maturity model. ISO 9001 is required by Air Force, maybe by OSHA. It is possible and we have a precedent in other areas.

Jeanne: EO is not chartered to do this kind of work. They do support materials, not standards. Needs to happen in the AG if at all.
… We haven't decided if it will be a note, etc. Its important that we all agree to explore this further.

Andrew: Is AGWG chartered to do this kind of work? Worth investigating before spending more time on it.

<sarahhorton> Speaking of ISO standards, ISO/IEC 30071-1:2019 Information technology — Development of user interface accessibility — Part 1: Code of practice for creating accessible ICT products and services https://www.iso.org/standard/70913.html

<jeanne> +1 to talking to W3C management, but we need a document to show them first

Andrew: Even though a maturity model is a good idea, I'm not sure if we would receive support to release as a note or rec deliverable.

Alastair: I think Michael was aware of it but I will follow up.

Janina: I agree, we should have wider conversation as this hasn't come up in W3C contexts. To build into WCAG 3, we'd need to identify normative/informative content and subject to debate.

<Fazio> we aren't shy about the workload

Janina: A note would be easier to tackle. It would be a easy starting point before AGWG charter is up for renewal.
… I strongly recommend note process but also agree about wider conversation. We are looking at third party in Silver...trying to encourage accessibility.

David F: The more detailed proposal includes normative requirements. We are considering that and need help.

Wilco: This could be difficult to tackle. WCAG 2 has a lot of limitations...writing a requirement that is limited to a sentence or two is difficult. We need different ways/tools of dealing with conformance reviews.

<KimD> Huge +1 to Wilco and the need to think in more inclusive/different ways

<Fazio> thank you, Wilco. Very insightful

<jeanne> +1 Wilco for having more tools in our toolbox to improve things for people with disabilites

Wilco: I encourage everyone to think about different ways of handling accessibility.

David M: Regarding EO, I understood their mandate was to provide information that would help orgs meet WCAG requirements. Not sure why they couldn't promote and publish a maturity model.
… Doesn't have to belong there, but seems worth discussing.

<Ryladog> +1 to David

Alastair: Chairs, Michael all need to catch up on charters and scope.

<jeanne> +1 to having Silver be a part of the AGWG

John A: This is useful work. The AGWG has felt like the WCAG 2 task force and Silver should be part of the main working group. Let's think about pulling issues like this into the broader group.

<Fazio> we meet wednesdays 8 AM PST

Alastair: Yes, we're here to make everyone aware of work such as this. Maturity model has been a subgroup within the TF so they are a step removed. We are working on bringing the groups together.

<Chuck> +1 we are actively working on combining teams

Alastair: Regarding next steps, we need to determine if it will be a separate note or part of WCAG 3. General feeling is that it might be better as a separate note.

<Fazio> We're open to all feedback

Alastair: I wonder if document needs to be adjusted to clarify how guidance will build on or provide guidance related to WCAG.
… Next steps are to give folks more time to review, David F and others will make updates, then bring to survey.

<sarahhorton> "separate note or part of WCAG 3" or a combination, some elements part of WCAG 3?

Alastair: Might need to be iterated upon.
… Questions/comments?

Proposal for migrating WCAG 2.2 Content to WCAG 3 https://www.w3.org/WAI/GL/task-forces/silver/wiki/WCAG3_working_process

<Alastair screen shares>

Jeanne: We do need to work more closely with AGWG and also plan to migrate WCAG 2 content. This (preceding hyperlink) is our initial thoughts about starting that process.
… We need more migrated content. Its part of the reason that our work on conformance has been slow. We need more data.
… Started by completely copying WCAG 2 working process page and based our process off of that as much as possible.

Alastair: Let's present as intended process, not necessarily ask for volunteers right now. We have an initial list of criteria although its not set in stone. A plain English statement would be helpful, to be followed by a survey and call for volunteers to work on SCs.
… Perhaps 5 people or so per group. Each group would need 1-2 weeks to prepare initial draft. A survey can be used to establish priority/order of SCs to migrate. Looking at 2 week sprints (scope, user needs, outcomes, tests/methods, etc.)
… Objections will be noted in survey at the end of each sprint. Criteria not agreed upon will be added to a backlog.

David M: Language of each SC that exist now took months to work on. Is it possible to migrate language over and then create a plain language description layered above each SC? Technical language can be difficult for people to understand.
… Technical language would be "legal" version supported by plain language text.

Alastair: Outcomes could be longer than plain language statements. Migrating SC text directly might not be workable. We definitely need to add more guidelines, and quickly at that.
… Without adding some content, we will likely struggle.

<Zakim> jeanne, you wanted to say that the orientation toward user needs changes the languages a great deal, as MATF discovered.

Jeanne: I have a slightly different perspective. We are trying to reorient existing accessibility guidance toward user needs.
… Mobile Accessibility TF took their SCs and followed WCAG 3 process (identifying user needs, working through testing and outcomes). That changed how SCs were oriented and wanted to be more granular.
… People generally seem to be supportive of more user need-focused approach.

<Zakim> sarahhorton, you wanted to say that the intent statements in the understanding documents work really well as plain language statements of the intent behind the SCs

Sarah: Regarding plain language summary, the intent statements are solid and address user needs behind technical requirements. With errors, we broke down into user needs (recovering from and preventing errors). In that process, we surfaced needs that are not currently addressed in WCAG.

David M: To confirm, a plain language statement will be provided by a more robust outcome statement. Outcomes will state when you succeed so will be longer. SC text will be shorter.

Alastair: That's my understanding...

<Jeanne confirms>
… If we allow for longer language with supporting plain language statement, we've broken existing cycle.

<Zakim> mbgower, you wanted to say I think trying to cast as wide a net as possible for any new 3 guideline can lead to a different and potentially useful perspective on outcomes

<bruce_bailey> AC: SC can be (1) easy to understand, (2) easy to test, or (3) short. Pick any two.

<mbgower> 2.4.2 Page Titled, 2.4.6 Headings and Labels, 2.4.10 Section Headings, 1.3.1 Info and Relationships

Mike: One concern is that it doesn't let us shift our view easily. Does it make sense to follow existing process with another group taking a more holistic approach? Might provide a different perspective.

Alastair: We do want enough content to experiment with. If we don't have enough migrated content, making a judgment might be difficult. Maybe we should have outcomes that can be later shuffled into different guidelines but not sure if that will be possible.
… We should try to get plenty of content in and shuffle later.
… next step will be to create a survey with a call for volunteers.

WCAG 2.x issue resolutions https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/

Alastair: Received plenty of 2.2 comments and have a large backlog of 2.x issues. Chairs are considering creating a separate meeting for those interested in working through 2.x issues.
… Will create a poll for the group to respond with days/times.

Error Identification, updated question #977

<Alastair summarizes survey topic and last discussion>
… Sarah is trying to distinguish between 3.3.1 and 3.3.3. Sarah, do you want to comment?

Sarah: If alert icon had an alt attribute, then visible text associated with it wouldn't be needed.
… Would be helpful to discuss what alt attribute value should be for icon.

Alastair: Assume it would be "required" or something similar.

<david-macdonald> +1

Sarah: Anything conveyed in alt attribute should also be conveyed visually. If description is necessary for non-visual interaction it would also be necessary for a visually-based interaction. Are we removing requirement for visible text? Icons have limits to what can be visually conveyed.
… Updated understanding doc removes requirement to have visible text.
… Is that what we really what we want to say?

Andrew: To clarify, understanding doc isn't normative so isn't changing requirements. SC doesn't require visible text but that error must be described to user in text.

<david-macdonald> I interpret that as a change in requirement. I've never understood this SC to mean an image can meet it.

Andrew: Agree that it could be clearer. Maybe we want to adjust moving forward. We also discussed personalization last week...although I'm concerned with rewriting. Regarding PR, I think we'd need an errata to change normative content.

<david-macdonald> text: sequence of characters that can be programmatically determined, where the sequence is expressing something in human language

Andrew: If we don't thoroughly scrub document, we open ourselves up to scrutiny.

Alastair: Many people have interpreted to mean that content must be supplied in text (alt text not sufficient). Difficult to get to text alternative definition from existing links.

<AWK> And that's why we can clarify that possible confusion in the Understanding document.

<Wilco> +1, this feels like a normative change.

David M: Echo Sarah's concern that it does feel like a change. Could try to add alternative text but that feels like a reach.

<AWK> text alternative: Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. Programmatically associated text is text whose location can be programmatically determined from the non-text content.

<AWK> (and text in that definition is linked to the def of text)

Alastair: People seem to have interpreted content in different ways.

Katie: I've always understood it to be programmatic and visible text.

<mbgower> As I noted last week: "It is perfectly acceptable to indicate the error in other ways such as image, color etc, in addition to the text description."

Alastair: This is tricky. I don't think icons are used that much for error messaging.

<MelanieP> Deque interpets 3.3.1 to include alt text

Wilco: In what case is an icon an error message? Icons do not describe the error. I don't feel like the update changes much.

Andrew: Example, if you have a triangle with an exclamation point, you can tab to it and either see or listen to detailed information.

Wilco: Doesn't seem like an appropriate use of alt text.

Alastair: All, please review issue and comment on updated content.