Silver Conformance Options Subgroup

25 Mar 2021


!, bruce_bailey, JF, KimD, Rachael, sarahhorton, ToddLibby, Wilco
John_Northup, Peter_Korn
KimbD, KimD, KimD:

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

<sajkaj> https://www.w3.org/WAI/GL/task-forces/silver/wiki/March_Report_to_the_Silver_TF#Report_of_the_Conformance_Options_Subgroup

<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.

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).