[Conformance] Minutes from 4 February

Minutes from the Silver Conformance Options subgroup teleconference of
Thursday 4 February are provided here.

===========================================================
SUMMARY:
Mostly, we developed use cases in realtime for draft Principle #2, "
accomplish a process with minimum difficulty."
===========================================================

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

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

   W3C

                                                                                                            - DRAFT -
                                                                                               Silver Conformance Options Subgroup

4 Feb 2021

   IRC log.

Attendees

   Present
          JakeAbma, jeanne, JF, KimD, PeterKorn, Rachael, sajkaj, sarahhorton, Wilco

   Regrets
          Jemma, Bryan, Bruce, John_Northup

   Chair
          sajkaj

   Scribe
          Wilco

Contents

    1. Agenda Review & Administrative Items
    2. Use Cases Discussion (Continued)

Meeting minutes

  Agenda Review & Administrative Items

   <jeanne> SK: Is there anything we need to review or revisit?

  Use Cases Discussion (Continued)

   <jeanne> ... notes that with multiple JS, Janina is SK (sajkaj)

   <jeanne> PK: reviews principles that need use cases

   <jeanne> ... minmum of time - can be measured with time. A possible example is a web page of not more than 1000 characters and 250 words may not have headers where the lack of headers is not an accessibility barrier.

   <jeanne> SK: We can set a minimum, although probably not a maximum.

   <jeanne> ... it's a good use case

   John: Things like word count related to internationalisation.

   Janina: Ran into that with HTML5

   <PeterKorn> Proposed use case [discussed 4Feb21]: A web page with a small amount of content (e.g. 200 words), split between two headers. The headers are only displayed visually, but not marked up as headers.

   Peter: added a proposed use case to the document

   Janina: User probably won't know which is the header and which is the paragraph

   Peter: Suggest, given that we know Silver addresses the use case, we annotate each use case as to how Silver might already address this, or mark if it does not already address it.

   +1

   Jeanne: This particular case is not currently covered specifically by Silver. It would be covered in the guidelines in the scoring.
   ... Good issue to raise to be corrected for the next WD.
   ... I think use cases are substantive that we can test the structure with. This is great.

   Peter: I've annotated this use case with Jeanne's comment.

   Jeanne: We wrote a guideline for headings that did not have a minimum.

   Peter: Heading guideline needs to be updated
   ... Any other "minimum difficulty" use cases?

   Wilco: Simple tables are a common example
   ... Two-column data table with only a few rows in it.
   ... It's commonly not failed, even though strictly speaking it probably should be.

   John: What about when a user increases the font size, and the table has a fixed with that gets overflowing or scrolling.

   Peter: closely related, but a distinct use case
   ... generalising; a table that resizes well to 180% but not 200%

   <Rachael> I think reflow is 400%

   John: What about an ARIA heading without a valid aria-level?

   Peter: Think we need to get more specific. Trying to tease out an area of a11y friction that doesn't exceed what we feel is only minimal difficulty.
   ... Related to something discussed in Silver; the spoons idea. If you have one rough patch issue it may be okay, but 50 is not.

   <JF> +1 to Jake

   Jake: 400% is the zoom option for reflow. It's not 400%, depends on your resolution.

   <Rachael> Agreed with the clarifications. Just didn't want to lose the point.

   Peter: This doesn't capture what might be lost for the user? Last part of a letter, entire word?

   John: If you have fixed with you get truncated text, but with relative with the table gets wider that introduces horizontal scroll.
   ... Where it introduces horizontal scroll, with a table and without is the same problem.
   ... Minor distinction between the two. Impacts the different users.

   Jeanne: Minor point, just because we haven't written the guideline, say something that makes it clear the guideline hasn't been written. Is a case to consider.

   Janina: can put in WCAG 2.x

   Jake: I hear 400%, but only very specifically mentioning 320px
   ... Only starts at 1280 with 400%.

   Peter: ... reading from doc

   <PeterKorn> Use case [discussed 4Feb21]: Text content that is fixed width in an initial viewport width of 1,280 pixels, but doesn't cause horizontal scrolling until the font size is increased beyond 380%

   <PeterKorn> (where the guideline potentially requires 400%). Users with motor/mobility impairments may have to scroll just a little bit horizontally to reach the final few letters of the content.

   Azlan: Introduce myself, new to the group. Something i wanted to get involved with.

   <Rachael> About the use case: It may be controls and graphics not just letters that require scrolling

   <PeterKorn> https://docs.google.com/document/d/1GyUYTnZp0HIMdsKqCiISCSCvL0su692dnW34P81kbbw/edit#

   Sarah: Wanted to add a use case of something that would fail a test, but would not have a significant impact.
   ... One I thought of is if a user wants to log in, and there is an error with the login inputs again without an error in that context, the impact of not meeting that guideline is less.
   ... Try to capture the context. In some case it could be a critical error. Capture what PwD want to accomplish on the site.
   ... I think the principle articulates that but the use cases don't do so quite as well.

   Peter: Think comments about the principle are important. Tried to write a new use case.
   ... Wonder if I should add a sentence about impact on this use case.

   Sarah: The way we think about it with errors is to ask what comes next for the user.

   <Zakim> JF, you wanted to ask about the error message. If its there, but not programmatically linked to the input that has the error... again, it's a scaled problem depending on individual users

   Peter: added another sentence.

   Sarah: What we're trying to get it is what is minimum difficulty.
   ... Don't think it should be "is clear". What do we know about this? Maybe we could say that someone could deduce that the next step is to try again, given the context.

   Rachael: Completely agree we need examples. Don't think COGA would agree this was minimal impact.

   <JF> +1 Rachael

   Rachael: For things like short-term memory, I may not remember where I was in the process of logging in. Without an error there is nothing to account for next steps. Other experts would have to confirm that.

   Janina: some sites only give you so many logins. That really would require an "attempt 1 of X"

   John: The impact of these errors depends on disability and severity of the disability. Hard to make these broad statements.
   ... If it's not programmatic, the impact on some users is great then on others.
   ... Different issues have different impact on different users.

   <Zakim> jeanne, you wanted to respond to JF about Critical Errors

   Jeanne: Would ask John to take a careful read of critical errors. Lot of it was done to try to address your concern.

   John: Whether it is critical or not, there will be degrees of impact.

   Jeanne: There is a lot to critical errors.

   Rachael: I think this area addresses the minimal. How do we identify that something is minimal? WCAG 3 has the structure to do this, but we have not identified how to define this.
   ... There would have to be a process to say something is an agreed upon minimal.

   John: have gotten push-back on that in the past.

   Peter: There might be a new principle to explore. One of the principles on network computing; failures may have to happen in the middle, the end may not know what happened.
   ... The software that is supposed to explain it might not actually know how to fix this.
   ... If those situations arise, what should the policy be if there is no way to know what the problem is and how to fix it.

   Jeanne: Is this something the errors subgroup is addressing?

   Sarah: Yeah, we're looking at this. This is helpful, the point of the use cases is to illuminate the validity of these principles.

   Peter: Reminds me to update "website" in the principles.
   ... maybe do that later in one pass.

   Jeanne: I think this is something Sarah's group is working on for a guideline.

   Peter: Only way to do this might be with external compute, such as voice recognition.

   <JF> Errors that when located within a process stop a user from completing a process (example: submit button not in tab order); and

   John: Read the critical section. Seems like can't find the error may be critical for some, but not critical for others.

   <Rachael> If it is critical for any, it's critical

   Jeanne: Critical errors are tied to outcomes. Outcomes are grouped together. This would be handled by outcome.

   John: So we have a use case, missing error message.

   John: Depending on an individual, anything can be critical at some point.

   Peter: No, not in every situation there will always be a problem for some group.

   John: didn't say group, said user.

   Janina: We can not build for each and every user. If most screen reader users can work with the resource, there will still be some that can't.
   ... There are going to be users that never grok it. You'll never get to each and every user.

   John: Comes back to the question of what's the minimum.

   Peter: Attempting to illuminate what we do. We're not trying to come up with the exact language at this time.
   ... It is WCAG 3 and the Silver TF that has the job to make sure this is addressed.


    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>