Meeting minutes
<ChrisLoiselle> Unable to scribe as I may need to step away, sorry! I'll scribe on Tuesday to make up for it!
Reminder of end of daylight savings time offset
jeanne: Reminds that North America and Europe will be back in sync as of next week with Daylight/Summer Time.
jeanne: Most of us are back at the usual offsets, but please check to confirm
joint meeting with ACT and Silver preparation
jeanne: A special meeting ...
<jeanne> https://
jeanne: Thursday 1 April at 1300Z
<Chuck> 7am my time
14/13/
<ChrisLoiselle> https://
<Jemma> s/1500z/9am eastern time
<jeanne> 1. Challenges Silver has with testability
<jeanne> 2. ACT lessons learned, to help with WCAG 3
<jeanne> 3. Next steps
jeanne: Agenda is three items:
jeanne: Wanted to discuss challenges with testability today so we can get to the meeting with concrete examples
<jeanne> https://
jeanne: reads from the comment ...
<Jemma> "Score 4 is the highest normative score (that counts toward the conformance total). The main LUT is based on the research of Dr Lovie-Kitchin, Dr. Legge, and others. See the bibliography.
<Jemma> Score 3 is intended as a "catch" for sites that, despite good design intent, missed in an area slightly, it is not much different than 4.
<Jemma> Scores 1 and 2 are considered "poor" and "deficient", they are degraded levels for catching sites that currently pass under WCAG 2.x, but have readability problems, giving site owners an opportunity to correct design problems without failing them outright, which would create an impediment to the overall acceptance of WCAG 3.0"
<Jemma> from git hub comment
<jeanne> Scores 1 and 2 are considered "poor" and "deficient", they are degraded levels for catching sites that currently pass under WCAG 2.x, but have readability problems, giving site owners an opportunity to correct design problems without failing them outright, which would create an impediment to the overall acceptance of WCAG 3.0
jeanne: Highlights lack of consistency in how we apply scoring across the guidelines
<PeterKorn> +1 to the idea of having a general verbiage of what each score "means"
jeanne: Any further examples we should list?
francis: Clear words, some met yesterday, mostly a quick checkin and next steps
<Chuck> sajkaj: Question - are we confident, is Coga confident that content usable meets clear words requirement?
<Chuck> david: Not line by line, but we did some review.
<Chuck> sajkaj: The question is important, particularly the word "persona". TO point out "what does one do", if one has a central word.
<CharlesHall> it is not commonly understood even within the UX audience
<Chuck> sajkaj: It is used. But I don't know that it's in any clear words vocabularly.
<Wilco> This seems off-topic
<JF> +1 to Wilco
<Chuck> david: Not necessarily whether or not the grade level of reading of the word (3rd grade for example), it's more is it abstract, finite, etc. Does persona fall into "abstract"?
<Chuck> sajkaj: getting off track.
<Chuck> jeanne: I add that at least the original clear words, there was an idea of an intent to allow exceptions for technical words that are defined. Content Usable would need to define "persona" and then we are covered.
<jennifer_strickland> From a UX perspective, "persona" is becoming a challenging word, and is trending towards "archetype" and other terms. "Persona" is more used for marketing folks nowadays.
jeanne: Asks Wilco what we should be prepared for?
jennifer_strickland: Notes persona now tending toward deprecation in UX
<Jemma> joint meeting topic will be related to 4th meeting topic today. - Willco's suggstion for bronze, silver gold options
jennifer_strickland: Moving to archytype
<Jemma> +1 peter
PeterKorn: Suggests large number of SC that need human judgement
PeterKorn: Also when update rate exceeds time to eval
jeanne: Asks Wilco for focus ...
wilco: measurability -- how to measure consistently and repetitively
Wilco: Not to say ACT isn't a good group for those other conversations ...
jeanne: Please forward other ideas in an e
report from Conformance Options: use cases
<Chuck> janina: We were looking at overarching ideas.
<Chuck> janina: Came down to use cases, and we've spent most of our time in this pace. Maybe a dozen.
<Chuck> janina: <audio issues>
<Chuck> peter: The ask was to deliver a few reports. We put this in our timeline for our sub-team, to first look at those use cases and through those use cases, and the principals behind them.
<Chuck> peter: Either the fpwd fully addresses, or we feel the structure of the fpwd could address so long as a not yet written guideline were written to cover the use case.
<Chuck> peter: That's our first report. We were only able to find 3 use cases that we felt were unambiguous in how silver was structured. They are in this report.
<Chuck> peter: They are all guided by one principal: If there are some issues on a page, view or path that are formal violations but don't really have a significant impact on whoever is using the app, that should not take us below the minimum acceptable score.
<Chuck> peter: I yield to Jeanne on how much time we should spend on this topic and the report.
<Chuck> Jeanne: At least read through the use cases, and give the team a chance to discuss and ask questions.
<Chuck> peter: They are all of the form "this would not be a pass" of the lense of wcag 2, but they weren't a significant impediment to use.
<Chuck> peter: A 200 word page, split between two headings. They are visually identifiable, but they are not marked up correctly. Screen reader users would not identify the headings.
<Chuck> peter: screen readers would need to read through the whole content, and would miss that the 2nd heading is in fact a heading.
<Chuck> peter: The sense of the subteam is that this would not necessarily be a significant imediment.
<Chuck> peter: This kind of situation need not yield a score below 80.
<Chuck> janina: back.
<Chuck> Jeanne; I don't want to discuss if this is really a significant or not a significant impediment. I want to discuss if this should be allowed to pass. That's the use case.
<Fazio> needs to have an aggregate
<Chuck> peter: I'm not suggesting that we write the guideline now, but we suggest the writers of the guideline consider this.
<Chuck> Janina: that's the outcome of the conversation in the last 2 weeks. We ended up with these 3, and focused on these 3. We saw several examples of how these could very well not be significant impediments.
<Chuck> Janina: The gap is "how do you know"? What are the steps to determine if these should pass even though the score isn't a perfect score. How do you judge?
<Chuck> Janina: We don't have an example yet.
<Chuck> david: To Janina's point, people with cognitive issues are impacted by these circumstances. It's important to maybe set a quantity, maybe 1 or 2.
<Chuck> janina: We call that the spoons problem.
<Chuck> Jeanne: Many aren't familiar with that term, may want to describe in another way.
<Chuck> peter: The cumulative <whatever term we end up using> friction.. that also is something that we didn't put in this report. It's an example of us finding that the fpwd doesn't have a clear way to cover.
<Fazio> +1 to peter
<jeanne> +1 that we have not addressed the friction across guidelines
<Chuck> peter: It's the cumulative friction of issues that span multiple guidelines. A complete interaction with a site involves friction.. one piece from each guideline, but never more than one, you still may have a cumulative level that's too high.
<Chuck> peter: That is an example of a challenge to the existing guidelines.
<JF> It's also worth noting that different users will have different tolerance for "friction"
<Chuck> Janina: We were taking them as isolated instances. Do you still have access and ability to complete the process? It's not optimal, but we thought small enough in most instances where you do get the info you need.
<Chuck> Peter: We have 2 more use cases and one more agenda item. Jeanne, do you want to do a deep dive, or discuss to understand and turn over to guideline writers?
<Chuck> Jeanne: Not a deep dive, but let's go through the queue.
<Chuck> Suzanne: An idea, it would be nice if there was a way throughout the guidelines if a reviewer could say "even though this scores poorly, I want as a reviewer to be able to determine that this isn't an impediment" or what if it is for 2nd graders learning to read? It could be a huge problem.
<Chuck> Suzanne: I think a lot of times these individual cases cause us to have to make all the guidelines different. It would be great if there was some exceptions to allow some thing, and if we had some to not allow some things.
<Chuck> Suzanne: What if the instruction covered an emergency situation? Then that heading is very important.
<Chuck> peter: I had some discussions recently, this is... 2 ways of handling. Maybe another focus on this. We should have a higher standard for healthcare related items, emergency related items. For these your target isn't bronze, it's silver or gold.
<Fazio> Interesting thoughs Peter Suzanne
<Chuck> peter: But if your use case is like training guides, you have a higher standard specific to those circumstances. All kinds of things that can be useful to using silver. Great sub-topic.
<Chuck> jeanne: 2nd use case...
<Chuck> peter: Table without row and column headers.
<Chuck> peter: In most instances they are layout, but you could have important information, without having the initial header row. This is an example that helps illustrate the principal of a technical failure that by itself a significant impediment.
<Chuck> peter: And one we felt that in the guideline for tables could be addressed in how it's scored.
<Zakim> JF, you wanted to note that there was not universal agreement to that last point
<Chuck> john: There was not a universal agreement to that. I disagree to some assertions. Just because it has 2 rows and columns doesn't suggest it's a layout table. Could be a data table. Broad statements and assumptions removes the concepts...
<Chuck> john: That the evaluations are contextual. In context of layout table, this... i context of data table, that... I want the concept to be aired on the table.
<Chuck> jeanne; we removed the line that "it's almost a layout table". This example is for the data table as an example.
<Chuck> jeanne: John's right the vvaluation is contextual. Something we have to decide if we want to address.
<Chuck> Jeanne: One of the original reasons for this group was to start testing for the design we had done for wcag 3 with specific use cases that tested the edges of what we were designing to see if this was doing what we want it to do.
<JF> Also to note that 'content' inside of the <td> would add to the contextual decision...
<Chuck> Jeanne: The use case is that this is a low impact table that would fail wcag 2, should it pass.
<JF> we discussed lists inside of a <td>
<Chuck> peter: Adding to this, putting these 3 cases forward, I don't believe our intent is that "this use case must result in a passing score", more to identify it as an edge case that we recommend that it be reviewed, in how data tables are scored.
<Chuck> Jeanne: We also discussed lists in a cell.
<Chuck> Janina: I want to speak to this point, a counter example: each of these design patterns, we can find a case where it's not advisable. We also thought that very often it's not a significant impediment. We are trying to allow for realistic imperfection. That's the premis.
<Chuck> Janina: Not sure regarding your point John.
<Chuck> Jeanne: That's something we want to bring to ACT as well.
<Chuck> janina: How do you judge when it can or should be allowable, or if it's a case that DOES create an impediment. LIsts in cell, braile.
<Chuck> John: Severity would change based on the user.
<Chuck> janina: We are looking at how to assess these.
<Chuck> Jeanne: 3rd use case.
<Chuck> peter: 3rd use case is of a type we find throughout our guideline. If the #2 pass is X, what happens if you are less than X. Fixed width content, at the edge of the 400% increase in size w/o causing scroll, fails.
<Chuck> peter: This doesn't cause scrolling when the font size is increased to 380%, but when you go beyond 380, but not at 400%, you do start to cause scrolling. There's scrolling at the edge on the boundaries.
<Chuck> peter: INdividuals with mobility issues may have to scroll a bit.
<Chuck> peter: This is something that could be handled in scoring, but not that it should be handled. We ask the question, this may be an example of a small impediment. What is the universe of small impediments?
<Zakim> jeanne, you wanted to say this is an excellent example of critical error 3
<Chuck> jeanne: Chair hat off, I found this one interesting because I thought it was a good example of critical error type 3, seems like a small impediment, but has a large impact on the user, especially if there's a large amount of text material to go through.
<Chuck> jeanne: one would have to scroll on every single line. That one works well with the other 2 for identifying the boundaries. We have a couple of small that could pass, and one that probably shouldn't pass.
<Fazio> I would say yes
<Chuck> peter: I wonder if the way we address C can be generalized to the friction. If the content is one line, and you only have to scroll once, is that different from 50 lines and 50 times required to scroll.
<Chuck> peter: I wonder if you have C generalize the cumulative problem.
<Fazio> it also depends how many pages it happens on
<Chuck> Janina: And shouldn't be allowed if an emergency alert.
<Chuck> Peter: This use case is it brings up some meaty topics to illustrate the kinds of thinking we need to do.
<JF> The problem there is testability at scale: is 1 line OK, but 50 isn't, what is the 'break point"?
<Chuck> wilco: I find it funny that I"m in the group and I had a different understanding of this case. 400% isn't achievable, but 380 is so close, that the actual % makes less of a difference than the font on the page.
<Chuck> +1 I thought that was where this was going.
<Chuck> wilco: something to think about.
<Chuck> Suzanne; I was going to say the same thing.
<Fazio> out of my realm
<Chuck> Chuck: These are valid thoughts for this use case.
<Chuck> Chuck: let it cover that one too.
<Chuck> peter: There are 2 ways this could be handled. If you have responsive content, that content can simply clamp the font increase to 380. That's the use case that wilco and suzanne were thinking about.
<Chuck> peter: as opposed to not clamping, and requiring the 400% scroll.
<Chuck> peter: ...to prevent clipping, this might be two use cases.
<Chuck> Chuck: both interpretations are reasonable points of conversation, maybe make 2 use cases.
<Chuck> peter: happy to rewrite as c1 and c2, or c and d. Happy to do so.
<Chuck> janina: Do we need to update this report? AS much as we need to update our use cases?
<Chuck> Peter: Depending on the parallelism, it's worth updating here to add use case D. So people who work on the horizontal guidelines can work on this right away, and not wait.
<Chuck> Janina: fair enough.
<Chuck> peter: Jeanne, do we have any information on which guidelines will be written next? It would be great if the next ones were headers, tables, etc.
<JF> headers or headings?
<Chuck> jeanne; Errors group started and is advanced. Mobile accessibility task force has started on working their guidelines to wcag 3. I'll talk more on Tuesday. Aside from that we don't have any scheduled.
<Fazio> 2.?
<Chuck> jeanne: We are starting the conversation about getting more people working on migration, but not that we can say yet.
<Chuck> Jeanne: not that we can say "here's what they will work on". We don't yet know.
<Chuck> Suzanne: should use case B be two use cases? One with headers across the top and one with them down the side?
<Chuck> peter: perhaps.
<Chuck> jeanne: Use Case B has NO headers.
<Chuck> suzanne: If you have a data table, but the headers are on the left, you don't get your info mixed up at all.
<Fazio> qUnless you set tab index
<Chuck> suzanne: If you put the headers on the top, could impact understanding.
<Chuck> jeanne: They are.
<Chuck> Chuck: Maybe for the use case library, but not for this doc.
<ChrisLoiselle> I'm not sure if this is helpful to illustrate the point https://
<Chuck> jeanne: Test all of WCAG 3 against, or for a specific guideline for table headers?
<Chuck> suzanne: I don't know. The impact on the user is significantly different.
<JF> which user suzanne?
<Chuck> suzanne: If separate, conversations might be faster.
<Chuck> peter: I've updated the page to update the use case C to C and D.
<Chuck> peter: And it need not be fixed width, just text that doesn't scale all the way. I could see THAT one split into 2.
<Chuck> peter: large and small text into 2.
<Chuck> Jeanne: That's not exactly how I heard wilco describe it.
<Chuck> Jeanne: It may be fatigue.
<Chuck> Jeanne: I didn't think it was about not scaling all the way, it was about scaling with a different ... requiring scrolling, and the other is being close to but not 400%.
<Chuck> peter: Maybe we split new C into 2.
<Chuck> janina: I wonder at the numbers there. It's really arbitrary is it not?
<Chuck> jeanne: it is, we've had proposals that want it increased way beyond 400%, that's a different issue.
<Chuck> peter: The scoring mechanism fits perfectly.
<Chuck> peter: You go beyond 400, you get more score, and under 400 but close, maybe not a fail.
<Chuck> peter: Font scaling guideline will need to think about and address.
<Chuck> peter: We don't solve it here.
<Chuck> janina: I remember how impossible it was when working on html 5.
<JF> +1 to Janina
<Chuck> janina: If we could do it without being arbitrarily specific, it would have gone in. We never figured it out.
<Chuck> janina: <describes the details of the challenge>
<Chuck> jeanne: Anything else to wrap up?
<Chuck> janina: My point is that the most acceptable in how to decide is to try and avoid arbitrary values.
<Chuck> jeanne: That's one of the things that came out of the meeting I heard, and wanted to bring here, the definitions of what is a critical error in each guideline needs to be more robust. Sarah pointed this out Thursday.
~s/1400/1300/
jeanne: Thursday 1 April at 150s/1500/1300/0Z
<sajkaj> s/1500Z/1300Z/
<sajkaj> s/1400Z/1300Z/