Meeting minutes
<sajkaj> Thanks, Wilco. We'll wait for you before closing on the draft report to the TF!
<sajkaj> akim, next item
Agenda Review & Administrative Items
<KimD> Janina: announcement: to EU participants: reminder about summertime/daylight time
<KimD> Janina: we should be in synch now again.
Continue work on March Deliverable -- Report on Use Cases https://www.w3.org/WAI/GL/task-forces/silver/wiki/March_Report_to_the_Silver_TF
<KimD> Janina: Report to Silver group (link above)
<KimD> JF: Reads report
<KimD> Janina: Comments?
<KimD> JF: Use case B: "almost a layout table" is making an assumption
<KimD> JF: we should account for both a real table and a layout table
<KimD> Janina: We thought of both ways - point is it's simple enough to avoid being an impediment.
<KimD> Janina: Compare to complex, large table
<KimD> Sarah: Can we talk through use case B and how WCAG 3 would address.
<KimD> Sarah: If 2 col table and no header labels, what are my outcomes?
<Zakim> bruce_bailey, you wanted to ask to strike almost layout table
<KimD> Bruce: We may not be able to work this use case through, even though it's a failure, it's unlikely to be a blocker
<KimD> Bruce: using 'layout table' isn't helpful
<KimD> Sarah: trying to be able to test the framework
<KimD> Bruce: example: table is name, phone number; name, phone number
<JF> <th>Janina</th><td>123-456-7890</td>
<KimD> Sarah: Would be we able to say this isn't a critical error?
<KimD> JF: Simple table w/ Bruce's table: still needs HTML associations. JF would fail it.
<KimD> JF: it could be a layout table, should still account for both tables
<KimD> Jeanne: Sarah's summary is helpful. Given current Silver structure, this simple table could pass because not a barrier.
<KimD> Jeanne: This would be addressed by silver structure
<KimD> Sarah: That's helpful. How will evaluator come to that conclusion?
<KimD> Jeanne: it would be in how the test was written
<KimD> Jeanne: the test would have to take that into account.
<KimD> JF: who decides if it's a critical error?
<KimD> Jeanne: test author, and assuming all the process around approval
<KimD> Janina: we'll need a metric that isn't so hard and fast as 2x2 grid, because it could still fail. For example, more than one line of content.
<KimD> Janina: like a list inside of a cell
<Zakim> JF, you wanted to ask Jeanne about my example
<KimD> JF: It's a fine line in what would pass and what wouldn't.
<KimD> Janina: how to resolve without asking for perfection
<KimD> Jeanne: we agree, doing it correctly gets more points. It can still be workable and thus NOT fail
<KimD> Jeanne: also, we haven't written the guideline yet. Point of use case is to see if this is something that could pass.
<KimD> Jeanne: with low points, but still could pass.
<bruce_bailey> @JF the point with my 2x name/phone number isn't that it's easy to fix, it's that a 3.0 review could allow a pass as-is
<KimD> Jeanne: back ground of use case would be helpful in the doc
<bruce_bailey> i am hearing Jeanne now saying something very similar !
<KimD> Janina: add a sentence that shows how we might let something pass without it being perfect
<JF> @bruce - sure, but I'm more interested in squeezing out, or limiting subjectivity: pretty much anything can be answered with "it depends", but that's hard to standardize
<KimD> Sarah: Todd and I talked about use case, wondering if it belongs here.
<KimD> Sarah: login form, when it doesn't work and comes back without an error.
<JF> Bingo!
<KimD> Sarah: WCAG 3 approach is missing related to severity and exceptions
<KimD> Sarah: i.e., a test that fails, but will it cause a block a person?
<Wilco> +!
<Wilco> +1
<KimD> Sarah: whether an error is critical or not isn't addressed by current framework.
<KimD> JF: agree with Sarah. Severity and criticality is unique for each person.
<KimD> JF: we need to find "break points"
<KimD> Janina: reminder, the use cases are meant to an illustration to show the grey areas
<KimD> Janina: "why did my login fail" question is one we've discussed. We can put it in this doc, it's in our Google doc.
<KimD> Todd: Not sure off the top of my head
<KimD> Janina: It's in the Google doc, and tried to put everything in a bucket.
<KimD> Janina: Not everything is covered, we're looking at edge cases.
<KimD> Janina: We can add the login use case.
<JF> +1 to Sarah
<KimD> Sarah: Seems all the current 3 use cases share the same issue: how do we clearly deal with failed tests?
<KimD> Sarah: Silver framework doesn't address
<KimD> Janina: do we want to keep this report?
<KimD> JF: Headings use case: it's both headings and properly nested headings
<KimD> Janina: issue is that the Headings are not there at all.
<KimD> JF: We need to address the Heading as an relationship/structure issue.
<KimD> JF: Details are needed because it goes to severity
<KimD> JF: Compares to zoom, where we have 200% and 400% - very specific
<KimD> Janina: We could write that use case with an arbitrary number.
<KimD> JF: Talks about data tables with multiple lines. Maybe word count is only one factor.
<KimD> Jeanne: Headings use case: we have Headings written. Can we work with ACT and see how they would address.
<KimD> Wilco: Agree, interested in what others have to say
<KimD> Sarah: Good idea, let's talk through that. In Methods, there are a couple tests.
<KimD> Sarah: passes one, fails one of the tests. How do I know the severity of the failure? How would I know whether it's a show-stopper?
<KimD> Sarah: That's the gap I'm seeing. How do you decide whether it's a blocker?
<KimD> Janina: Is issue where to score on the scale?
<KimD> Sarah: Tests don't indicate anything about score; they're just T/F.
<KimD> Sarah: Scoring has info, methods have info, but there's no bridge.
<KimD> Jeanne: Example, please
<KimD> Sarah: Say I've done the tests, one fails, I record that. Next step is determining criticality.
<KimD> Sarah: Missing heading, but then have to determine if missing heading is needed to complete a process.
<KimD> Sarah: Does that identify if that failure translates to a significant impediment.
<KimD> Sarah: Needs to be more fleshed out because there is a gap.
<JF> A HUGE +1 to Sarah's points
<KimD> Jeanne: Agree, so decision of "critical failure" needs more detail
<KimD> Janine: You don't get the info and the structure isn't there via headings, but it can be figured out.
<KimD> Sarah: Also need to look at frequency. That goes to severity.
<KimD> Janina: "the spoons problem"
<KimD> Wilco: Are the test cases getting in the way? We know the problems, maybe the test cases need to be clearer?
<KimD> Wilco: Headings use case seems to be about severity/criticality.
<JF> Functional Performance Statements
<KimD> Wilco: should we express that rather than the use/test case. Maybe we report missing pieces, drop test cases.
<KimD> JF: Criticality/Severity? FPC might address; deals with impact on individual users.
<KimD> JF: Blend of pass/fail and severity. Depends on user though.
<KimD> Jeanne: That example isn't relevant (blinking/flashing not an issue if user has no vision). I think we've addressed that.
<Zakim> bruce_bailey, you wanted to suggest that conversation about critical errors is not really helpful to this use case challeng
<KimD> Jeanne: Can you tell me if we haven't addressed?
<KimD> Bruce: Use cases are helpful and important; but "criticality" isn't relevant to this conversation.
<KimD> Bruce: We're talking about edge cases.
<JF> I think the point is Bruce that for any individual, an error may or may-not be "critical"
<KimD> Bruce: They way they're written, it's clear they are not critical errors.
<KimD> Rachael: "Critical error" - capture it as a question to be answered later.
<KimD> Janina: Do you recommend presenting and say that's why criticality is important?
<KimD> Rachael: Yes, we have ambiguity and need to work it out. Can be tied to examples or not.
<KimD> Jeanne: Examples help clarify and make it more understandable.
<KimD> Janina: Any objections?
<KimD> Wilco: Have issues and have examples go with them
<KimD> Janina: We know we need more work on authoring.
<KimD> Jeanne: Agree, point is to flesh out areas that need more work.
<KimD> Janina: We can flesh out more.
<KimD> Janina: We need to report in March. Anyone uncomfortable with our approach? Should we report out?
<bruce_bailey> +1 to reporting
<KimD> Wilco, Sarah: ok with that
<KimD> Janina: Still need to work on GitHub issues.