– DRAFT –
Maturity Model

Discuss any activities the Task Force might want during TPAC in September. Are there other W3C WG we want to have a joint meeting with? What agenda for those meetings? Note this is NOT about any breakout sessions we might want to hold on Wednesday of TPAC

Fazio: Who do we want to meet with at TPAC?
… focus perhaps on groups outside of our typical sphere of influence

janina: Can be other WAI groups as well (as APA Chair, I want to be sure we request everything required)

Fazio: A good example was last year when APA sat with Verifiable Credentials and DIDs

Lionel: Brainstorming, maybe we want to reach out to ISO, IETF, or even AGWG regarding the personnas

janina: This suggests we might want to meet with EO

Fazio: Makes me think, we would like to see how our less technical, more process oriented work will be greeted by other groups

Lionel: Choose a group that has GAFA-type companies

Fazio: Yes, we can make an effort to get in front of Apple, Google, etc.

Review Susanna’s updates to Support Dimension https://lists.w3.org/Archives/Public/public-maturity/2023Apr/0013.html

<stacey> would someone be willing to screen share? It errors out/won't allow me to open

Jeff: I am concerned that the inclusion of physical accessibility is out of scope
… we are focused on IT accessibility

Fazio: We hvae discussed that physical access is a pre-requisites to many aspects of IT accessibility

Lionel: +1 to Jeff

Fazio: I remind us, this is a maturity model, and the items are not required

Brian: This is overlapping with Personnel as well, as it involves the ERG

Jeff: The definition of 'Support' is a bit vague
… in the current model
… the definition could be seen as exiting the IT accessibility scope

stacey: Are we including work accommodations in the work place?

Fazio: This support needs to go into everything, and the amount of support hat you provide depends on how mature you are
… we are saying, the most mature type of organization can do this.

Jeff: +1 to Brian's thought, that these should go into Personnel
… I thought 'support' was when somebody with a disability came to a website and it is not accessible
… or a PWD who is having problems with a screen reader
… that is the kind of Support this was intended for

Fazio: I agree and disagree
… We want to refer to both internal and external support
… there is a section called Customer Support

Jeff: That is her proposal, correct?

<stacey> For support items that are out of scope for this model, potentially we could include suggestions for where a company could go farther for disability inclusion in the workplace that they could explore/resources?

Jeff: This is a very big change in one go.

Lionel: How shall we work best as a Task Force to edit these lines?

Jeff: We should think about whether a line should be here or not, before we edit it

janina: Built environment might be able to stay if it is part of intranet support, the ability to request accomodations from an internal support team
… but I agree with Jeff we have to keep out pure built environment things, in an extreme sense

<janina> CloudFlare Employee Accessibility: https://blog.cloudflare.com/introducing-flarability-cloudflares-accessibility-employee-resource-group/

Jeff: Can we collaborate in a Google sheet?

Lionel: We may want a Google Doc, it can support wider collaboration and more comments

Fazio: Yes, that might work

Fazio: I will create a Google Doc for the section that we are group editing

Jeff: I note that changing format to a Google Doc might confuse things

CharlesL1: Suggest we have the original author attend the meeting to share what she was thinking

Fazio: I will invite

Some of the design process questions seem to make sense for large organizations where process, templates and checklists are more formal parts of a large organization. Were there discussions of how these might be framed for small organizations? (e.g. not having a formal design review process, but we do have design reviews; is the way forward to become more formal even if the team has three members?)

<CharlesL1> Some of the design process questions seem to make sense for large organizations where process, templates and checklists are more formal parts of a large organization. Where there discussions of how these might be framed for small organizations? (e.g. we do not have a formal design review process, but we do have design reviews; is the way forward to become more formal even if the team has three members?)

Fazio: The intent of the maturity model is to formalize processes and continually improve them
… while an individual item may not make sense at a particular time
… due to revenue, personnel, technology, or other limitation
… as long as you are using the MM you are aware of your status, where you are, and where you should be going

Jeff: +1 to Fazio

<CharlesL1> Under 3.4.1.2 Development category of proof points, the examples of “Accessible developer implementation resources” seem more about information. Where might you consider software and hardware tools that help with accessible development, such as access to screen readers or switches?

Under 3.4.1.2 Development category of proof points, the examples of “Accessible developer implementation resources” seem more about information. Where might you consider software and hardware tools that help with accessible development, such as access to screen readers or switches?