<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.
<AWK_> +AWK
<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?
<silence>
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?
<silence>
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.
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]