Meeting minutes
Agenda Review & Administrative Items
Janina: standard agenda, no announcements
<PeterKorn> Announcement: https://
Peter: We launched support for connecting hearing aids to fire TV.
Continued Discussion https://raw.githack.com/w3c/silver/use-cases-apr22-js/use-cases/index.html
Janina: Started a discussion last week, not sure if anyone has had time to work on this.
<jeanne> https://
Jeanne: I stared moving examples into GitHub
Janina: We might use these as we refine them.
Jeanne: I still have an issue with the heading, needs to be a W3C heading.
… I put in abstract, document status, and the introduction
… When we get into the situations, there were some minor changes. I gave each example its own heading so it'd be picked up in table of contents
… No changes other than formatting for situation 1 and 2.
… I started with example 3.1. I started breaking it down so it applies specifically to the example.
… I took those directly from WCAG. I think we can add more to this.
… The next one, I broke down identifying core functionality.
… I didn't go far into accessibility policies. I left that generic. I want to see if people like this approach.
… The request was to make the title WCAG 3 use cases for conformance
Peter: Like where this is heading. I wonder if the second bullet; guidance on prioritizing critical errors best lives in a technical standard or in company guidance.
<PeterKorn> ack
Peter: I wonder if that better lives in accompanying guidance, rather than technical standard.
Jeanne: I think you're right.
Jeanne: I'm not sure what'll go forward, but we did have three levels of critical errors.
… interference, then task completion. Those are technical.
… The idea in the first one, I broke down examples of non-interference.
Jeanne: I'll put specific examples of types of critical errors related to task completion
Gregg: Love this document, but continue to have concerns. We talk about situations where technical guidance will be hard / impossible. Under technical we should have nothing but the word "require"
… We can require or have exceptions. Guidance is in the second category. We don't put guidance into technical document because of length. That's why we have understanding documents.
… A lot of these, under technical we should say nothing. There's nothing we can do. This is a policy issue.
Gregg: if it's a policy issue it's not technical.
… We are in WCAG 3 trying to figure out how to get beyond the testable / required.
… If we're going to go beyond that, we will have to add guidance in some other layer.
… I'm hopeful we can make the additional guidance testable. I.e. instead of testing the page you get a higher score because you did something, made a claim, carried out a process. This is testable.
Janina: I think it's correct to say we put guidelines into guidance.
… I think we might just leave attestation as part of requirements. Tell us you've done it, show us the process.
… Maturity model hopefully will be a form that will help you track what you were doing to conform to XYZ requirements.
… That might help with attestation. We may not agree on what a good test is. But there is this cascade of things we know you shouldn't be doing, like flashing content.
… It's not just going to be one spec or one document, a number of documents coming from different groups.
… We have an obvious one for policy; timeframe. We won't say how much time an organisation needs, but regulators are well attuned to that.
<Zakim> janina, you wanted to suggest timeframes for policy
<Zakim> jeanne, you wanted to say "guidelines"
Jeanne: Ultimately what we're writing is guidelines. Guidelines give guidance. I do believe it belongs in a technical standard.
… One of the very important results form the Silver research was that people love the guidance of WCAG 2.
… That's why I disagree that we can't say guidance under a technical standards.
… I can certainly adjust the wording to make it clear this is on technical requirements of WCAG 2.
… We already know that non-interference SCs are the most important to fix right away.
… We can pull those out to say you must do this first.
Jeanne: We could start giving a number of requirements from ATAG, and that would be a clear example. This one is harder to do because it's so broad.
Peter: I want to speak on guidance. I don't disagree, but there's an important step, that is defining levels of criticality.
<jeanne> +1 to removing Prioritizing'
Peter: If I dropped the word "prioritising" then the technical standard isn't taking a position on the order, but it's giving a latch point for policies to say, you can take up to N months to bring content in compliance, however within the first X days you must address the critical ones.
… For this one and quite a few others, having that basic latch point of defining what is truly critical is important.
Gregg: Makes sense. Even in WCAG 2 criticality was indicated with levels.
<Zakim> GreggVan, you wanted to say "make 4 categories instead of 3. 1) Technical changes (requirements), 2) Guidance within the Tech Document (guidance beyond requirements), 3) Supplementary Guidance (Understanding WCAG 3), 4) Policy Group/Agency Actions and to say "make 4 categories instead of 3. 1) Technical requirements, 2) Tech Guidance - within the Tech Document (guidance beyond requirements), 3) Supplementary Guidance (Understanding WCAG 3), 4) Policy Group/Agency Actions
Gregg: Jeanne mentioned those are guidelines. None of those are what people pay attention to. What people pay attention to are success criteria.
… Guidelines are the direction. Interestingly in 3 we still have guidelines, we then have requirements, and maybe below that more detailed guidance to get higher badges / levels.
… In particular I think maybe we should have 4 levels. 1. Technical requirements.
… Next is technical guidance. Things in the technical document as guidance. That's where we go beyond requirements. I'd personally like to get process things into testable.
… Third is guidance, this goes into understanding and advice to policy makers. In understanding docs we can always say what we think policy makers should do.
… The fourth level is policy, here's where we write things we can put into the third level.
Shadi: Mulling over it. I wonder if it's getting too much into separate places.
Gregg: For WCAG 2 for the longest time we wanted 2 levels, we went on that for the longest time.
… Everyone wanted to have 2 because people wanted to take AA either in A or in AAA.
… By having the technical requirements be one category, and then have a second category of technical guidance.
Shadi: The focus I'm thinking about is to think more broadly and recognise that WCAG isn't responsible for everything.
… There are other areas of responsibilities.
… The categories made some sense, it matches a bit what we have in WCAG 2.
… I think there are general techniques.
… There's no reason we can't have a best practice technique for sign languages.
… But I lost track when it went to levels. That seems like a different thing.
Jeanne: We're trying to make a shift away from A - AAA levels. What came out of the design sprint was that we'd look at the imporance of the task, rather than say anything for text alternative is level A.
… We could say for example this icon is a control in the navigation, that's more important than a graphic in the footer.
… What they wanted us to do is look at how it's used to set the criticality of it.
… I don't want us to get bogged down into separating out the technical requirements.
<Zakim> jeanne, you wanted to talk about the paradigm switch away from A AA AAA.
Jeanne: It would make this document unnecessarily complicated, and it might build in some assumptions that other groups may take in a different direction.
… I think I'd prefer the levels we have
<Zakim> GreggVan, you wanted to clarify 1) Technical requirements, 2) Tech Guidance within the Tech Document (guidance beyond requirements), 3) Supplementary Guidance (Understanding WCAG 3, Techniques, etc.), 4) recommended Policy Group/Agency Actions (these would end up in the guidance docs in 3 as guidance to policy people - along with our guidance to authors or others)\
Gregg: To clarify, the level discussion was an example of criticality we did in the past.
… I always worry about other people deciding whats important or not.
… Even if you decided it was an example, we're getting into real detail about what's critical and not critical.
… It's like having laws, if I'm sitting at a red light 3 in the morning with nobody around, I still wait for it to turn green. Not because it's important, but because it's the rule.
… If as drivers we start deciding when something's important we get accidents.
… I'd rather figure out what the really big issues are, rather than fine tune.
Shadi: I think we shouldn't swing too far the other way. Traffic lights do have sensors, there are other ways to do things.
… It's about finding a balance.
<SusiPallero> fantastic meeting today!