Meeting minutes
Agenda Review & Administrative Items
janina: Let's step back and look at what we've done so we can get work in mind for the hybrid TPAC upcoming.
janina: TPAC is in Vancouver the week of Sept. 22
janina: AGWG has announced intention for the week to meet in person with the hybrid meeting option.
janina: We are aiming to end all W3C meetings 5-10 minutes before the top of the hour.
Meta Discussion: TPAC and Beyond
janina: We've been looking at Gregg's proposed edits to the document that Shadi did a lot of good work on.l
<maryjom> s/on.I/on./
janina: We've had several efforts on "all software has bugs" and other situations with debate on publishing a FPWD on the challenges for conformance.
janina: It was published as a FPWD. Much of that high level document is saying what we are seeing in presentations made to AGWG on the topic.
janina: Jeanne would likely say that the Silver requirements gathering and design was also thinking about these conformance challenges over the years.
janina: Are we spotting patterns?
janina: In the 4 iterations we've worked on, there are certain SC failures we'd call critical. We can debate on the length of that list of critical failures or if everything is equally weighted.
janina: Writing a metadata description of accessibility features that would be valuable to capture. So may want to build on existing schema work or build on top of schema.org.
janina: How do we want to focus our work so we can talk to AG WG at TPAC and have a meaningful conversation?
janina: We might want to have a 1/2 page position or point of view.
GreggVan: We keep hashing over the same kind of things in different ways. We need to take the next step to have some proposal of what AG WG could agree on.
GreggVan: We need to work toward a resolution. Our last document starts with examples, which is great, but it has a lot of repetitive content adding to the length of the document.
GreggVan: We might want to collect those things that are generally true. Work on what's underneath the examples.
GreggVan: On meta level, the examples are great. May want to have a short description of the examples but that may not be a good use of time. We can edit to reduce verboseness.
GreggVan: Under technical - we talk about policy which is out of scope for technical. If nothing technical exists, we should say there's nothing.
GreggVan: The guidance really just says we need to make recommendations in policy.
GreggVan: We should reduce to 2 parts: the examples and supplementary guidance which includes the policy. Reducing content is key or it will be ignored.
GreggVan: Critical errors is a different topic from this document currently. We've always had critical errors - but who are they critical to? That's different for different users.
GreggVan: The metadata description is kind of a conformance statement.
janina: Metadata intent to document what it has or doesn't have.
Wilco: People are continuing to push back on 3rd party conformance issues as part of this, and we want them to be part of this discussion.
<Zakim> jeanne, you wanted to say the use cases to look for patterns of solutions and stop the technical and policy discussion
jeanne: The value add we have for AG WG is we have the use cases that any conformance proposal will need to address.
jeanne: The conversation about conformance may become a popularity vote on the use cases unless we have sufficient ideas on how to address them.
jeanne: We should go to TPAC with those use cases - a good set of them and pretty well evolved ideas on how to meet them.
jeanne: We should focus on how can have a productive conversation.
<Zakim> GreggVan, you wanted to say -- I think I might be in the category of "3rd party is policy - not technical"
GreggVan: +1 to Jeanne. We have to have as much as we can to propose how to integrate these ideas
GreggVan: You can't call something accessible that doesn't fully meet all of the requirements. We should have a policy recommendations document that addresses the "reasonable" aspects.
GreggVan: We don't want to call something that doesn't fully conform "accessible"
janina: Some are nervous about the integration aspect. We need to bring some examples along as examples. In YouTube, who is responsible to add captions.
janina: The cost to do all of the captions is a huge amount of money.
janina: It's a slippery slope and we have to find ways to bring folks along before we talk about integration.
janina: I propose fleshing out this document and we can move it to an initial publication. We might want to create different views of that document - one for policy/regulation, one for standards.
janina: This could potentially avoid radically different standards/policy around the world.
janina: Have a list of situations with pointers into the details. (a high level view)
janina: If we identify patterns, documenting those may provide a good overview.
<Zakim> jeanne, you wanted to say that I don't agree with Gregg's assertion that we can't address the problem with technical standards. We should try to get as much as we can into technical to support harmonizations
jeanne: Concerned that the tough issues are being pushed to policy. Because this leads to fragmentation. Standards provide harmonization.
jeanne: Industry and people with disabilities need harmonization. Managing how quickly to fix, how much to fix per country will be super-difficult to manage.
jeanne: We have to look at it so policymakers will harmonize their requirements on tech, industry/vendors can have a more consistent way to address accessibility...
jeanne: ...and users with disabilities will know what to expect.
GreggVan: We should have a pair of documents: Technical standards document and a policy recommendations document.
GreggVan: We did a good technical standard and that's being used worldwide. If we also had a policy document to be adopted worldwide that might solve the problem.
<SusanaPallero> I agree with Gregg on not calling conformant products that are not accessible when it is not possible to do it for other reasons
GreggVan: I can't say an inaccessible page is accessible. Answering if certain inaccessible content needs to be fixed in a certain amount of time or at all should be policy.
<SusanaPallero> other than techincal
<jeanne> I don't think I said that WCAG3 say that it is accessible, only that it passes -- the same way that WCAG2 passes content that is not accessible.
janina: Sounds like we should get more specific on the policy aspect. E.g. a library has a lot of inaccessible content. Can you make it accessible on demand and who should fund that.
janina: We need to figure out who should be in that conversation if we are developing those kind of things.
Wilco: Things that conform to WCAG aren't necessarily accessible. The bar shouldn't necessarily be at the same level no matter the size of the organization or the amount of content.
Wilco: Accessibility is not the same as electrical safety.
GreggVan: You should not have different levels of requirements for different sizes of company.
GreggVan: If one person doesn't need to follow the rules vs. another, that's also a policy issue.
GreggVan: Policy sets who has to follow the rules.
GreggVan: Then in practice, you can modify the policy to better fit.
<SusanaPallero> Digital accessibility is a Human Right comprehended on the Right to Access to Information, that means that even though a lot of countries may not have digital accessibility laws, they do have other processes for people to claim the compliance of these Rights. In those cases, judges, lawyers and technicians, turn to the WCAGs to determine if the product is accessible or not. And we may say something about this not being "one siz[CUT]
janina: We need to identify the parts where we disagree and work on those.
GreggVan: I will continue to work on the document to try to incorporate what was said today. Anyone who wants to help let me know.