Silver Community Group Teleconference

11 Jun 2019


(no, one), ChrisLoiselle, alastairc, LuisG, CharlesHall, JF, Chuck, Makoto, AngelaAccessForAll, shari, Jan, johnkirkwood, bruce_bailey
Shawn, Cybele, JohnKirkwood, Denis


<LuisG> howdy

<LuisG> thanks :)

<LuisG> well, the baby had a round a little while ago and I hadn't been able to get back to sleep

<LuisG> so I figured I'd at least hop on and listen in on what's been going on

<ChrisLoiselle> Hi Luis, I'm on call, but no input for voice / phone

<LuisG> ah, cool

<LuisG> was actually just checking if my audio was working :)

<CharlesHall> theme of meeting = Super Good

<CharlesHall> actually, the WebAIM Million report shows 33.1% of top million sites missing a document language.


<CharlesHall> migration is more important for the information architecture which intends to decouple that conformance level from the guidance. it is first about organization, then about editing.

<jeanne> regret- JohnKirkwood

<scribe> Scribe: Chuck

Jeanne: Welcome alastair and andrew. An update has been asked for by the main group. Hope it's a regular occurrence. Trying out.
... this is the first time and it's an experiment. Alastair and Andrew go for it.

Alastair: Latest agenda for AG group is representative of our work. Mix of WCAG 2.1 and 2.2.
... Going into beginning of rechartering (setting up what entire group is going to work on).
... Looking at links at charter review would give a good idea of what the entire group is working on.
... Main AG calls is mix of 2.1 and 2.2.
... We published 2.1 last year. There are still resources that need to be crafted. Techniques.
... Each week we are prioritizing 2.1 techniques.
... We go over them, review, change as needed, and get published.
... Understanding docs aren't part of official spec. We can publish every week.
... That's what we prioritize. We are also working on first pass of WCAG 2.2.
... We asked folk to get into small groups and draft sc.
... It might be worth having a little review of what some of those sc are, because it gives an idea of gaps we are filling in 2.2.

<alastairc> https://docs.google.com/spreadsheets/d/11IKqjRFvkRd2dAfUiyc5whhB3yIYXvSiirWct7KQIB0/edit#gid=0

Alastair: General spreadsheet <link above>
... Won't go through all of them, but good to tackle a few of them, give a general description and review.
... Inside baseball. Silver will have to deal with this as well.
... This will give a flavor of a very content focused model (has advantages and disadvantages).
... First one is "accessible authentication". From coga task force.
... If you are getting challenged, transcribe numbers from one place to another, use memory, advanced cognative..
... That will be a struggle to log in. Intent is to minimize the cognative required.
... Small sites may have their own users and passwords, and may not have different styles of login.
... Other end of scale is email services, with their own styles. Reset loops are difficult. You can't send user email to click a link.
... Different scenarios. It didn't get into 2.1 because we could not fulfill all the various scenarios.
... That changed recently in 2.2. There's a web authentication specification which allows for biometric, offloads authentication to os
... Windows hello, apple equivalent (face recog, fingerprint), usb devices...
... That's more feasible to do. It's first in our queue (this sc).
... Are there any q about this?
... Is this an interesting way to provide updates?

Jeanne: you mentioned different user needs. Is there a place where these are documented?

Alastair: From coga there is a massive doc called gap analysis. Has large tables of user needs, categorized. Been there for a while.
... That's the basis from where the sc came from.

Jeanne: We would need to find in coga doc.

Alastair: If you go to github page, it's linked from there. Look for "gap analysis".

<AWK_> https://www.w3.org/WAI/GL/wiki/WCAG_2.2_Success_criterion_acceptance_requirements

Andrew: It's not all in one place. For each sc we have acceptance requirements. That's one place where the process is different than in the past.
... More formal. In the past an sc could get in the editors draft if we had the text and good sense that it was possible to implement.
... We are ramping that up more. Before it goes in and public sees it and people get too invested we want to make sure that there is techniques and content.
... Make sure that there is sufficient implementations and that's all documents. The user needs would be part of the understanding content.

jeanne: Can you give an example of how WCAG relates to ICT?

<alastairc> https://www.w3.org/TR/wcag2ict/

Andrew: WCAG to ICT. Working group note that describes how to apply the criteria to non-web.
... Section 508, EN 301 549 for applying WCAG to non-web and software.
... We still need to update it for WCAG 2.1. But we don't want to fall behind, so it's a requirement for 2.2.
... Easiest SC is "it's applied as written". It avoids undue references to web pages or something very specific to web and software non-web docs.
... I suspect silver will make that happen more automatically, but worth keeping in mind.

Alastair: Silver approach wcag to ict wouldn't be a separate approach.

Jeanne: Good. That's re-assuring.

Alastair: Should I do another one? Or we move on?

Jeanne: I'd like to hear more about the process you are following. That's exciting. Good process, something we should look at.

<alastairc> https://www.w3.org/WAI/GL/wiki/WCAG_2.2_working_process

Alastair: We've got this wip document. Worth considering because silver is going to be filling in content. You need some kind of creation and review process.
... We've been trying to treat it like a backlog.
... Link is what we are aiming for in 2.2. We've got an initial list of sc. We've tried to make it so that we have small cross-discipline groups.
... That are drafting the sc. In the past a communication headache would be individuals who write something that makes perfect sense to them...
... But doesn't fit into the framework.
... Starting from a user need point of view. But for wcag need to decide what's a pass or fail.
... We are having people doing it for years working with sme's.
... It's a mix of people working as a small group. When it goes to wider group that's for review.
... Feels harder going, it's necessary process. In smaller group more easy to colaborate.
... It's been somewhat successful, a bit slower than I prefer. But that's the aim for our initial creation process.
... Once there is an initial draft, we are looking to do 2 week review sprints. Review is specific because that's when it goes to whole AG group.
... Then there's a week to address comments and then another review.
... At the end of that review we use survey to decide if it can advance to editors draft, or have comments on why it's not there yet.
... If not ready for editors draft, goes back into backlog.
... It's not disappearing or dropped, just goes back into the queue.
... Gives people space to consider the issues.
... The variation, we realized while authoring, there's probably another step where each small group creates the doc...
... The sc, explanation, the test procedure which helps thinking about it. Put that up for initial review before working on the bulkier docs.
... There's an initial "kick the tires" approach, for a quick review to decide if it's feasible, if there are major blockers.
... If we get past that stage, then it's worth going to the bulkier docs.

Jeanne: Where do you see that in your docs of the process?

Alastair: After 4... we thought we would have 13, we had 4.
... It's around #5 where we are having this initial review.
... We aren't entirely sure if it will be testable. It's a case of not wanting to commit people to lots of work if it's a dead end.
... If you modify the sc text, that could have massive impact on the understanding docs and techniques.
... In silver scenario you are encorporating existing criteria which has already been proved feasible or new content.

Jeanne: This is very helpful. This is what we've been doing the past 2 weeks is defining the process of how to create the documents for each sc.
... We've been focusing on #4. Adapting what we've done for #4 and including that in the broader process.

Alastair: Presumably your initial backlog is the WCAG sc.
... I'd split that down and prioritize those, and maybe include a few that we've struggled to get in.
... We do have 4 that are in the 2.2 set.
... It's getting to up for review fairly soon.
... Those ones are going to stretch where we are with WCAG due to the conformance model.

Andrew: We started the call talking about the conformance model. That's where it gets interesting, because of the conformance model for WCAG.

Jeanne: I agree.

Alastair: Any other questions on process?


Alastair: How are we on time?

Jeanne: This is the major thing I wanted to work on in this call. If we want to have more conversation I'm happy to have this fill out the time.

Alastair: We could talk about focus more visible, color algorithm updates.

<alastairc> As an FYI, DEEP dive: https://github.com/w3c/wcag/issues/695 /

Jeanne: Can you talk about the color algorithm? We have been working on contrast, and this would be important.

Alastair: We have color contrast criteria and non-text contrast criteria. Contrast testing relies on a specific algorithm from late 90's early 2000s
... There's a few considerations. Potentially better algorithms to use. Which would give a better match...
... The original testing Bruce confirmed was aimed at color blindness and related issues, and low vision.

<bruce_bailey> Also see: https://github.com/w3c/wcag/issues/360

Alastair: Research was more on color blindness. Regular people who are not color blind look at color combinations that fail...
... that pass but are hard to read. Bruce posted in one of several long threads on the issue.
... One aspect of the algorithm. We are in favor of updating as long as we don't lose the color blindness aspect.
... There's also state transitions. When we defined non-text contrast we wanted to encorporate states like focus and active.
... Where we ended up, hard to cover in the same sc. It has contrast, it's change has contrast.
... Blue button with white contrast, and reverses when it has contrast. That's an obvious change, but no measurement of adjacent colors.
... When you transfer from one state to another, no adjacent color to measure.
... We are focusing on that transition, specifically for focus. There are a lot of different states (16 different state for links).
... We did need to be quite specific and we've already got focus visible sc. We are looking to extend or add to that sc.
... We have algorithm, states, and other factors that impact readibility.
... Imagine you have white text on black button. harder to read if black button is on white background instead of on a darker background.
... Local adaptation means ideally we would want to account for what the area around the text is, not just immediate background.

<alastairc> https://alastairc.uk/2019/04/oddities-in-color-perception/

Alastair: We have no idea how to do that or test that. For those on IRC I did a post <link above>
... We have new ag member who will join low vision, Andy Summers.
... Very knowledgable, and we need to harness that to help with our work.
... there's also different styles of fonts.
... We have broad brush testing on small text and large text. If it's large doesn't need as much contrast, small text needs more contrast.
... There's a lot of nuance that can be gone into.
... google accessibiliy team did some research on controls.
... Other factors beyond non text contrast.
... That didn't immediately bring out things we can use but it did highlight that there are other factors we should consider.
... There is pleanty we want to improve upon in later visions.
... Reasonable overview Bruce?


Jeanne: Should we postpone color contrast sc until this stabelizes?

Alastair: I can't see this going into a 2.2 apart from the algorithm update. Likely to be post 2.2. You would want to migrate current sc, but assume changes in future.

Bruce: two hard outcomes. One is our reference in WCAG is out of date, the other is one of the numbers is wrong...
... But that doesn't impact the math. For silver its worth still talking about (simple stuff like dark on light).
... I'm not convinced we need a radical version of the formula.

Jeanne: This shouldn't be too hard to do in the future.

AWK: Two problems are same problem. Old version of formula.
... We can get that improved in 2.2. For silver, it would be interesting if we can get away from using a formula at all.
... If structure and conformance model allows for personalization and content allows it.
... If we had a different approach that solves all of those problems that would be ideal.

<Zakim> JF, you wanted to note that we need a mechansim for repeated testing

JF: We are going to need a mechanism for measurement. Existing algorithm or something different.
... The reason.. different monitors and different lighting systems would impact.

AWK: It would need to be testable. You would test the users ability to adapt the color. Instead of saying colors have to be static...
... Users would be able to make the changes, and everyone gets what they want/need.
... We would still need something to deal with images of text.

JF: User can modify it, maybe if device allows. Sounds and feels like user style sheets.
... I wouldn't know how to do that on mobile phone and tablet.
... At end of day a testing algorithm, maybe multiple algorithms...
... Feels like when measuring colors, we need a standard.

<JF> Chuck: another issue we've noted - when we talk about migrating from 2.x to Silver, we find it "blowing up" - the scope of the exercise gets a lot more complex

<JF> Chuck: what we need to figure out is how to move a SC to Silver, without review, or do we do a holistic review and move forward that way?

<JF> We need to make a decisionh and stick to it

Luis: We were going to try and do better.

<JF> Luis: I thought we had decided to try and not just a straight migration

Luis: Big advocate of doing straight port and then afterwards make improvements.
... I thought it had been decided.

Jeanne: As we dig into practical side... how do we take existing sc and make them broader and make them non-web, we hit some stumbling points.
... We are looking at doing a more detailed analysis of looking at what moves directly and what doesn't.
... We've been working on a process doc last couple of weeks.
... Has come a long way in last month. We need to finish some. Then discuss and refine process.

Time check.

Jeanne: Thanks AWK and alastair. Very excited about your process and integrating what we are doing.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/06/11 14:32:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/QWe/We/
Present: (no one) ChrisLoiselle alastairc LuisG CharlesHall JF Chuck Makoto AngelaAccessForAll shari Jan johnkirkwood bruce_bailey
Regrets: Shawn Cybele JohnKirkwood Denis
Found Scribe: Chuck
Inferring ScribeNick: Chuck

WARNING: No "Topic:" lines found.

Found Date: 11 Jun 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]