[Conformance] Minutes from 25 March

Minutes from the Silver Conformance Options subgroup teleconference of
Thursday 25 March are provided here.

===========================================================
SUMMARY:
One topic: Discussion of the draft March report to the Silver TF
===========================================================

Hypertext minutes available at:
https://www.w3.org/2021/03/25-silver-conf-minutes.html

===========================================================

   W3C

                                                                                                            - DRAFT -
                                                                                               Silver Conformance Options Subgroup

25 Mar 2021

   IRC log.

Attendees

   Present
          !, bruce_bailey, JF, KimD, Rachael, sarahhorton, ToddLibby, Wilco

   Regrets
          John_Northup, Peter_Korn

   Chair
          Sajkaj

   Scribe
          KimbD, KimD, KimD:

Contents

    1. Agenda Review & Administrative Items
    2. 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

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



----------------------------------

Janina Sajka
Accessibility Standards Consultant
sajkaj@amazon.com<mailto:sajkaj@amazon.com>